On 2007-06-21 04:03, Perry Lorier wrote:
james woodyatt wrote:
On 20 Jun 2007, at 15:10, Mark Smith wrote:
On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[EMAIL PROTECTED]> wrote:
I'd be more sympathetic to arguments like this if we RFC 4864 didn't
insist on recommending the deployment of stateful packet filters in
IPv6 that break most of the things NAT breaks in IPv4.
I'd like to say, as co-author of RFC 4864, that in my mind it simply
recognizes the reality that firewalls exist, will exist for the
foreseeable future, and will include stateful filters, so we have to
deal with it. (more below)
How does a stateful firewall, present on the end-node itself, cause
these problems?
We see this all the time today with stateful packet filters in IPv4
nodes at global unicast addresses. Application binds to a socket for
accepting connections, but that isn't enough for accepting incoming
connections. Application need to obtain authorization to request the
firewall to allow incoming connections. That involves asking a user
for a password. Bletch.
And then there is no real standard for asking for that authorization in
the first place. A lot of applications embed UPnP, which I guess is as
close to a standard for being able to request a listening port as we
have. Many protocols have ways of testing to see if a listening port
really is listening, since there is no real local feedback from
firewalls that your listening port is being filtered or NAT'd or had any
number of other things done to it.
And then we get software developers abusing what is really a bug in
stateful boxes in the name of "nat transversal". Operators and end
users regularly say "Your new application should support nat
transversal" rather than fixing the underlying problems.
Moreover, firewall knows how to track state for TCP and UDP, because
that's all the transports the IP stack knows about. It would be
reasonable to port implementations of SCTP and DCCP to live there as
well, but nobody bothers because the firewall doesn't know about those
transports and needs to be taught about them from scratch.
Consequently, applications that should use DCCP or SCTP, use TCP or
UDP instead, so they can work with the firewall interface they have.
Firewalls don't get upgraded to support SCTP and DCCP because
applications are all limping along with TCP and UDP. Egg: meet chicken.
And these boxes don't support this "new fangled" IPv6 thing either.
Operators claim theres no point in pushing IPv6 out to customers coz
their CPE's don't support it.
All true. So please start a thread on the v6ops list about
draft-ietf-v6ops-cpe-simple-security and draft-woodyatt-ald,
where there is some attempt to tackle these issues. James is too modest...
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
