On Tue, 19 Jul 2005 09:44:57 -0700 "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx> wrote: > > I'm concerned this may usher in DNS SRV message filtering in > > addition to protocol port filtering. > > Why? > > My post pointed out that use of SRV is essentially neutral with > respect to protocol filtering. It makes it easier to filter well > behaved protocols, it does not prevent stenographic approaches. Fundamentally the use of SRV for service location may be a fine idea. Practically, at least in my experience, fundamentally new and easily identified fields (e.g. ECN or in this case SRV or a new RR type), will be ripe for filtering and will be filtered, often by default. This may not be such a big deal architecturally, since it doesn't necessary change current or future network policies. Operationally it will add additional complexity and another unique vector for network fragmentation. From an operational perspective, I'm not interested in any more options to make it easier to increase either. I might question the value of this approach now, though I would certainly encourage experimentations to see how this might turn out. > >From a security point of view there is a big difference in the > accountability structures when dealling with protocols that require > prior bilateral discovery (e.g. tunneling botnet control packets over > HTTP) and those that allow for unilateral session initiation (e.g. > tunneling botnet control packets over IRC). I'm not following what you mean here. Note, there are some, though not as prevalent, botnets that natively use HTTP for control. > There is a reason that the botnet herders stick with IRC despite the > fact that it is routinely blocked in corporate environments. Systems > that require bilateral discovery are very hard to set up and fragile > in operation. Systems with a common signaling mechanism are in > practice much more robust. Those points are probably debatable. IRC is often used, because it still generally works well to control botnets. I don't think HTTP botnets are necessarily any harder to setup and maintain and I think one could argue that they could be even easier to setup and maintain. > Promoting everything to the DNS level means that an ordinary Internet > user can enfrachise their Internet connection simply by purchasing > their own DNS name. You may be right and it may work better than what we have now. My primary suggestion was to consider making the actual socket parameters negotiated and bound only to the local/remote address/port pair. Though perhaps that may complicate stack implementations with questionable end value. > There are security concerns here, but remember that according to > today's standard Internet firewall configuration externally facing > systems live separated in their own DMZ in any case. The only protocol > access allowed is from the inside to the outside. Yes, and many configurations also strictly limit what services are allowed from the inside to the outside. John _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf