On Tue, 19 Jul 2005 09:44:57 -0700
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
I'm concerned this may usher in DNS SRV message filtering in
addition to protocol port filtering.
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.
Ietf mailing list