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