On Wed, 20 Jun 2007 16:11:01 -0700
james woodyatt <[EMAIL PROTECTED]> 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.
> >
> > 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.
>
While I agree that isn't the ideal interface, I really think that
mostly is a user interface/OS implementation problem, not a network
architecture or protocol problem. Why should we "fix" the problem
within the network when the problem is fundamentally occuring at the
boundary between the application and the OS i.e. the networking API.
I'm sure you know this, security comes at the cost of
convenience. If somebody doesn't want to have to "put up" with these
sorts of prompts, then I think that means that they've got their
security settings too high or too sensitive.
Effort certainly needs to be put into trying to make Internet security
as convenient as it can be. However, a line has to be drawn to identify
the point where if security is made any more convenient than "this",
security is being compromised, and people will be forced to make a
choice between convenience and security.
> 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.
>
Well, most of the ADSL CPE that my company sells to customers runs
Linux internally (and this is 3rd party commodity CPE, not something
we've put together ourselves). And here is what I've found under the
manual page for the current version of the command line firewalling
configuration utility :
dccp
--source-port,--sport [!] port[:port]
--destination-port,--dport [!] port[:port]
...
sctp
--source-port,--sport [!] port[:port]
--destination-port,--dport [!] port[:port]
--chunk-types [!] all|any|only chunktype[:flags] [...]
The flag letter in upper case indicates that the flag is to
match if set, in the lower case indicates to match if unset.
So once a web interface is wrapped around that and/or appropriate
defaults are set, I think the chicken has not only hatched but it is
nearly roasted. Of course these devices are also doing NAT commonly, so
at least for IPv4, it'd be somewhat of a wasted effort.
> > It seems to me that you're making the assumption that the only
> > scenario IPv6 will be deployed in is one where end-nodes always
> > have an upstream stateful firewalling device.
>
> This is likely to be *more* common in the future than it already is
> today. Residential IPv6 gateway devices are shipping now in consumer-
> grade Wi-Fi AP/router products, and they include these packet filters
> turned on by default. More are forthcoming. Their owners are rarely
> even made aware of these packet filters. Most won't discover them
> until they try to do something silly and stupid, like receive
> incoming VoIP calls over IPv6, fail utterly, and then *maybe* track
> down the source of the ICMP "administratively prohibited" errors to
> their own router.
>
Ask yourself what is the most widely used communications device that
people use. If you can't guess that, ask yourself what recently
announced product from your employer has generated worldwide publicity,
popularity and demand months before it is going to be released, even in
places where it is unlikely to be released in any time soon.
Will that have a firewall on it, or will the customers of that also
have to buy an iFirewall to go with it, because the device itself won't
do firewalling, even though I'd be guessing the OS sitting on it is
easily capable of doing so, and would have enough processing power to do it.
If it doesn't have firewall on it, and the customer doesn't have a
bluetooth or wifi iFirewall in their pocket, where is the carrier going
to put the firewall for all of their customers. How is that firewall
going to scale to support 1000s, 10s or 100s of 1000s of updates to
rules. How is that central firewall going to protect the device from
other malicious customers who are also behind it, and therefore who's
malicious traffic doesn't go through the upstream carrier firewall (I'm
guessing that teenagers would get much more fun out of DoSing the old
man down the road's phone rather than one overseas, because they might
be able to physically see the reaction)
What I'm interpreting you to be saying is :
(a) you seem to be making a very broad and general statement that NAT
is necessary for IPv6
(b) yet your only deployment scenario is one where there is an upstream
stateful firewall that is owned and in control of the person who owns
the downstream devices, and is in close proximity to the devices that
it is protecting.
You may not be exactly saying (a), however it seems to me you're going
close to it.
My argument to those points is :
(a) lets not assume NAT is the only way to solve these problems, as we
already know, recognise and suffer from problems that NAT has created
from IPv4. Let's get creative, and try to solve these problems without
incuring the costs of address translation.
(b) don't assume that what is most likely to be the most common IPv4
case is going to be the most common IPv6 case. Even better, think about
how and where IPv6 is different to IPv4, and try to then identify
possible scenarios that were impossible with IPv4, and then ensure that
IPv4 "thinking" applied to IPv6 doesn't inherently preclude options
that are only possible with IPv6.
> Architecture is hard, folks. Despite our best laid architectural
> planz, we are certain to be plagued with middleboxes at every level
> of the Internet. They're going to interfere with everything.
> Basically, if it's known to work today over IPv4/NAT, then there's a
> pretty good chance it will still work tomorrow over IPv6. That's
> about the best we can hope for at this point.
>
> If NAT between PA and ULA-C unicast addresses solves a problem for
> somebody, without breaking anything important that isn't already
> broken by something else we've already done, then why shouldn't we be
> pragmatic and define a mostly sensible way for them to do it?
>
That's the crux. Why is NAT immediately sensible, just because it was
somewhat effective in IPv4, when we're moving to something new ? It
reminds me a bit of the cliche, "if the only tool you have is a hammer,
every problem looks like a nail."
> p.s. Readers are encouraged to consider whether this message is a
> devil's advocacy.
>
>
That's fair enough, but the devil also usually wants you to accept
things you really shouldn't, and you'll end up paying a price far
higher than you ever imagined :-) People, including me, call NAT "evil"
for a reason :-)
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
