On 2011-09-29 10:28, Dan Wing wrote:
>> -----Original Message-----
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Roland Bless
>> Sent: Wednesday, September 28, 2011 2:04 PM
>> To: Joel M. Halpern
>> Cc: 6man
>> Subject: Re: Centrally assigned "ULAs" for automotives and other
>> environments
>>
>> Hi Joel,
>>
>> On 28.09.2011 22:39, Joel M. Halpern wrote:
>>> Then use a good firewall to control what is and is not allowed to
>> pass.
>>> What I am objecting to is requiring an ALG, and using addressing to
>> try
>>> to create security.
>> Sure, ALGs are ugly, but usually you don't want
>> any kind of unwanted traffic on safety critical internal
>> devices (think of flooding, sending exploit packets etc.).
>> Furthermore, I'm very pessimistic about end-system security.
>> IMHO we will never see exploit-free implementations given the ever
>> growing complexity of our systems. Allowing a direct end-to-end
>> communication to internal devices IMHO increases attack possibilities.
>> An ALG has the advantage that you have more possibilities for policing
>> and that any not explicitly modeled communication cannot pass the ALG.
>
> ALGs are harmful and the NAT industry has over a decade experience
> that shows ALGs are harmful.
+1. I think the problem here is trying to provide some kind of
transparency where it is in fact impossible and even
undesirable. I'm surprised that the target is either an ALG or a
simple proxy. I would think that you would actually want an
application server at the boundary, acting for example as a data
collector on the ULA side and as a data provider on the "uplink"
side. There might also need to be a firewall router at the
boundary for regular Internet access from users inside the
vehicle, but that would be a standard CPE in most respects and
would not be handling vehicle data.
(Much the same applies to building automation, except that that
doesn't require mobility support.)
Brian
ALGs have prevented proper operation
> of SIP, FTP, and a variety of other protocols. The more complex
> a protocol, the more likely an ALG interferes with the complex
> protocol -- rather than helping it. This is because the ALG makes
> naive assumptions of message flows and interfere with advanced
> functions the protocol would like to do.
>
> An ALG also requires unencrypted communications (so the application
> can be examined) and, if the application payload is supposed to be
> modified, also requires using no integrity checking. That means
> the entire system has a greater attack surface just to allow the
> ALG to examine and to modify the packets in transit.
>
> An ALG also complicates upgrading protocols. Protocol changes have
> to be done so they remain compatible with the remote system (always
> a requirement) as well as with the ALG (which is a requirement because
> of the ALG). This increases the complexity to the protocol, especially
> as the ALGs, themselves, evolve and have their own bugs fixed, but
> are not proper, signaled elements in the architecture.
>
> -d
>
>
>> Regards,
>> Roland
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
