Subject: RE: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 19 Jul 2005 09:44:57 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of John Kristoff

> On Fri, 15 Jul 2005 11:48:28 -0700
> "Hallam-Baker, Phillip" <[email-masked]> wrote:
> 
> > There are certain limitations to the SRV prefix scheme but 
> these are 
> > entirely fixable. All we actually need is one new RR to allow one 
> > level of indirection to be introduced. With that in place it is 
> > possible to use prefixed SRV records in place of port 
> assignments and 
> > prefixed TXT records as a means of expressing protocol 
> configuration 
> > information.
> 
> 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.

The firewalls are having to become more complex to respond to current
protocol developments, in particular the emergence of Web Services. The
Web Services stack is designed from the ground up to support protocol
filtering at the SOAP layer so SRV merely represents a means of
pre-emption.

>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). 

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.

There are two objectives here: maintaining the traditional openess of
the Internet and ensuring that the Internet is secure.

These objectives are not necessarily in conflict. But they will come
into conflict if people refuse to accept that there are legitimate
interests on both sides. 

If we take the SRV mechanism seriously and take our duty to our users
seriously we can significantly improve the Internet experience for the
ordinary user and make it much easier to deploy new Internet
infrastructre.

To answer what I believe John's core point is here: The use of SRV will
actually advance the cause that I suspect the is promoting: Specifically
the enfranchisement of the ordinary Internet citizen.

Promoting everything to the DNS level means that an ordinary Internet
user can enfrachise their Internet connection simply by purchasing their
own DNS name. 

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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John Kristoff <[email-masked]>
Date: Tue, 19 Jul 2005 17:07:03 -0500

On Tue, 19 Jul 2005 09:44:57 -0700
"Hallam-Baker, Phillip" <[email-masked]> wrote:

> 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.

> 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.

> 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.

> 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