[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
application listener discovery in the presence of stateful firewalls
everyone--
This is a continuation of a previous discussion under the subject
"Re: The argument for writing a general purpose NAT for IPv6."
On Apr 26, 2007, at 14:35, Tony Hain wrote:
james woodyatt wrote:
I should also mention that my additional concern about applications
that haven't yet been developed is part of what has me champing for
an alternative to deploying ALG's everywhere. It would be nice to
have a long-term solution that didn't require constant upgrades to
the middleware.
That was the point of IPv6.
Perhaps. I'm not sure it *remains* the point.
From where I sit, it looks like we're all about restoring the
Internet to a single, universal addressing realm. There does remain
some politicking on the side about address space resource
allocation-- but, that seems aimed more at promoting transition in
the minds of those who don't comprehend the addressing realm issue.
(I'm doubtful that a political campaign will work, because I think
the intended audience is at least smart enough to understand that
economists know a lot about the practical matters of allocating
scarce resources.)
My biggest worry about IPv6 is that transition may be slowed or even
halted because of the basic problem that applications which work over
IPv4/NAT today can't be made to work over IPv6 too, without still
deploying ALG's everywhere and/or developing the moral equivalent of
UPnP IGD and NAT-PMP (minus the UNSAF aspect).
Again, take a look at m2m-x. My comment to them was to use IPsec
for auth
between the client and the firewall for pinhole management, and to
specifically insert a local SIP proxy for cases where the
enterprise does
not want to allow the carrier to manage the firewall pinholes
directly.
I've seen many proposals like this over the years. I don't like them
for three reasons:
1) they're separate from the IETF standards that specify the
requirements for
IPv6 nodes and routers, and therefore likely to be available
only on a
limited subset of the Internet to a limited set of applications;
2) they require application layer protocols to participate in
network layer
signaling; and...
3) they don't permit peer-to-peer applications to work without
relying on the
availability of a third-party relay service.
In my humble opinion, this class of solutions represents a perversion
of the Internet architecture-- though I recognize the IAB vigorously
disagrees with this view.
I think applications shouldn't have to ask the network to see if they
will be able to communicate before they begin communicating. They
should just attempt to communicate directly and offer users
information to facilitate troubleshooting when communication fails
for policy reasons. These systems like m2m-x, ICE, STUN, etc. don't
permit that-- instead, they require applications to communicate with
a signaling rendezvous point to set up the network to allow
communication to take place before they can initiate direct
communications between user endpoints. They're necessary evils where
UNSAF methods are required for any communication to happen at all.
They're an abomination in the absence of network address translation.
I do still think there is a huge, glaring, problem before the V6OPS
group, involving 1) unmanaged IPv6 networks subject to policy
enforcement by 2) unmanaged stateful packet filtering firewalls.
Whether that's really an open problem in the NAP draft, I'll leave to
others to decide.
You will have a very hard time with 'unmanaged' in most of the
IETF, because
they are all technologists that understand how to manage, and most
of them
build products for professional managers so they just can't get
their minds
wrapped around the complexity that goes into masking the guts from
the end
user. Never mind the logical disconnect between 'policy
enforcement' as a
management function and the need to do that in an 'unmanaged' way.
I'm referring to unmanaged networks in the sense defined in section
5.2 of RFC 2462, particularly with regard to the "OtherConfigFlag"
conceptual variable:
OtherConfigFlag Copied from the O flag field (i.e., the
"other
stateful configuration" flag) of the most
recently received Router Advertisement
message.
The flag indicates whether or not information
other than addresses is to be obtained
using the
stateful autoconfiguration mechanism. It
starts
out in a FALSE state.
In addition, when the value of the
ManagedFlag is
TRUE, the value of OtherConfigFlag is
implicitely
TRUE as well. It is not a valid
configuration for
a host to use stateful address
autoconfiguration
to request addresses only, without also
accepting
other configuration
information.
At least with DHCP6, you can imagine defining some options for
telling nodes on "managed" networks, i.e. those with OtherConfigFlag
set TRUE, about firewalls that have to be signaled to make
applications work. If there is no configuration service, however, I
don't see how nodes can discover firewalls to signal without either
1) doing something really noisy, or 2) adding a new router
advertisement option to help control the problem. New router
advertisement option definitions, I'm told, are a tough sell in IETF.
The point you make about conveying to IETF regulars the complexity
of, the importance of, and the foresight required in choosing
appropriate defaults for consumer-grade network appliances is well
taken. It's clear to me now that the IETF has applied less thought
to making the Internet easier for ordinary people to use than to
making the operation of Internet services easier for technocrats to
manage. Hopefully, it's not too late to do something about that.
--
j h woodyatt <jhw@apple.com>