RE: hop-by-hop and router alert options

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@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf