hi pekka,
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?
the signaling protocol itself should be considered separate from the qos
model.
you basically have two models:
a) model 1: central entity has topology knowledge and knows which router
needs to be configured
b) model 2: discovery mechanism is more intelligent and figures out where to
install qos reservations
the authorization aspect is not necessarily tight to either one of the two
models since you can offload the authorization decision to another node
(which is heavily done today in many places - not only qos signaling).
- 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.
i actually do not see this issue. with both, path-coupled and
path-decoupled, signaling protocols you can learn this information.
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.
why do people want to reuse a path-coupled signaling protocol for
path-decoupled signaling?
since i spoke to them i might reflect their opinion: they thought that it
would be good to have one protocol instead of many protocols (also based on
the similarities between the two "models"). i also think that this is true.
slides (and possibly the meeting minutes): i can ask marcus brunner and
forward them to you.
- 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.
addressing the router with a udp/tcp message would also require some
processing and would slow it down.
however, if you want the router todo something then you should have a way to
signal to this device.
some other folks have responder to this issue with interesting remarks. this
is something which deserves further considerations.
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?
that's certainly true. if you only rely on router alert options (as a
discovery mechanisms) then this is certainly an issue.
since we were aware of this issue (based on an analysis of henning and ping)
nsis allows other discovery mechanisms to be used.
btw, the fact that a few messages are sent towards the destination address
does not mean that they need to reach the destination address. some usage
scenarios.
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.
i am not sure about this statement. not every router in the world needs to
inspect packets with router alert options.
the fact that many routers forward ip packets that contain any ip options
through the "slow path" is (i think) a leftover from old days.
in other proposals for signaling protocols, for example yessir, routers
intercept certain udp packets.
do you think that this would improve the situtation?
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?
it is true that some methods use tricks (by tunneling everything through ssh
or http). however, with the combination of sip + midcom there are no tricks.
it "only" requires that a sip proxy is able to inspect the sip message and
knows which firewalls to configure. if the sip proxy is not co-located with
the firewall/nat then you need to use a separate signaling protocol (such as
snmpv3 - selected by the midcom wg).
if you would equip every firewall/nat (in your network) with a sip proxy
then you only need to use an api to configure these devices. as a result you
have a very expensive signaling protocol. if you additionally use sip aware
firewalls which transparently inspect the bypassing sip message (intercept
the messages based on the ports used by sip) then you actually have a
path-coupled nat/firewall signaling protocol based on sip. this approach has
a number of disadvantages but it illustrates the relationship between
path-coupled and path-decoupled signaling protocols. it additionally shows
the difference between inband and out-of-band signaling.
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.
you can treat ike/ipsec as another example of a firewall signaling protocol.
ike provides authentication of the end points and provides a secure
signaling protocol to create, delete and modify security associations.
section 4 of <draft-tschofenig-v6ops-secure-tunnels-01.txt>, for example,
says:
"
A compliant implementation MUST NOT allow instantiation of an ESP SA
that employs both NULL encryption and no integrity algorithm.
[Section 4.2 of [I-D.ietf-ipsec-rfc2401bis]]
"
the nsis nat/firewall signaling protocol does not aim to create ipsec sas.
hence, it does not address the part of protecting data traffic.
hence, i think it is not totally bogus to assume that people want to use a
protocol to talk to their firewall to allow certain type of traffic to go
through.
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.
this is the place where the philosophical mismatch happens. the end host
oriented approach assumes that the network is rather stupied whereas the
other approach assumes that the network does the job.
* 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.
you might be interested in an also failed bof in this area:
Distributed/End-Point Firewall Control BOF (defcon)
(see http://www.mail-archive.com/new-work(_at_)ietf(_dot_)org/msg00008.html).
i also found the idea interesting.
- 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.
the terminology in this area is somewhat vague (e.g., difference between a
stateful packet filtering firewall and a symmetric nat from a firewalling
perspective).
anyway, i hope that the work in the behave (not yet) wg will help to
investigate these issues a bit further.
for the specific nat/firewall signaling problem described above a nat helps
to provide a generic solution rather than one with works only in specific
networks.
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.
i need to re-read the proposal carefully in order to respond to your
comment.
- 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.
you missed my point. pricing is a complex topic but we (nsis wg) do not try
to solve it (and it would be outside the scope of nsis anyway). it is just
an issue you need to keep in mind and it appears in many other places as
well (you might also include the economical benefits of the introduction of
ipv6 as another area). you cannot stop working on protocols only because you
don't know how the pricing scheme would look like in the future.
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).
it is certainly a good idea to look at scenarios which do not always require
true end-to-end signaling.
nsis also focuses on these scenarios.
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.
i think that this is in general a good suggestion . i will certainly keep it
in mind.
ciao
hannes
--
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf