Re: [Fwd: [Saad] Some initiating thoughts...]

> 
> Internet Engineering Task Force                                      IAB
> INTERNET-DRAFT                                         Mark Handley (ed)
> draft-iab-addressing-2003815.txt                          15 August 2003
> $Revision: 1.1 $                                  Expires: NOT PUBLISHED
> 
> 
>                  Architectural Issues with IP Addressing

Some comments on this draft.

> The Internet is a complex and heterogeneous network, and becoming more
> heterogeneous as time goes on.  Different people and different
> subsystems in the network have different requirements on the addressing
> architecture; this is a classic example of a "tussle space" [3] between
> conflicting demands.

A very interesting and important question in my mind is whether
the underlying requirements are on the addressing architecture, or
whether this is merely one way to express some functional requirements.

For instance, one stated requirement can be expressed as:
 - the need to do more fool-proof configuration of IP address-based filtering
   in firewalls (and provide defense in depth for IP address-based filtering)
or it could be expressed as
 - need to encode security domains in the syntax of the IP addresses (in order
   make IP-address based filtering easier)

My gut feel is that the underlying issue is that firewall/filtering
configuration is complex and error prone and that there is a question
on the table how we can make this easier. For instance, are there architectural
modifications that can improve the situation?

In section 3.2:
> We note that the
> use of private addresses with a NAT instead of a correctly configured
> firewall has significant shortcomings from a security point of view, but
> it does have the advantage of being very simple to set up.

This seem to implicitly imply that a non-NATting firewall is (significantly)
more difficult than setting up a NATting firewall.
My observations (from SOHO DSL routers at home) is that the configuration
task (i.e. not the administrative task of requesting a /29
IPv4 prefix) with IPv4 is just the ISP configuring the prefix into the router.
With protocols like DHCPv6 prefix delegation that manual task goes away.
The set of SOHO routers I've been exposed have by default a "outbound only"
firewall; whether or not NAT is used. I don't know how common this is,
and whether it applies in the enterprise space.

Thus the above statement in the draft my reflect common perception more
than reality; while perception is important we should try to separate that
out from reality.

Next paragraph:
> Irrespective of the technology used to accomplish it, the specific
> security requirement that enterprises have on addressing is that it
> should be easy to set up a well-known and well-understood filter at
> security boundaries that reduces the exposure profile from individual
> configuration errors.

Since the whole draft is about IP address architecture there is an
implicit statement that the above security requirements and filters
at the boundary are only about IP addresses. Of course that is false since
the wast majority of such filtering also look at protocols, TCP/UDP port
numbers, and higher-level state.
I think the draft failing to make this point can lead us to incorrectly
believethat having multiple of addressing scopes to match multiple
of "security domains" is a pannacea for filtering at the boundaries.

Section 3.3:
> A key requirement on addressing is that much of this consumer equipment
> (printers, light switches, etc) needs to be able to communicate locally
> without being directly exposed to the global Internet.  At the same time
> the same network infrastructure will be used by devices that do need
> global Internet access.

I think this view of consumer equipment not benefitting from globally
communication is very short-sighted.
For instance, today I see benefits of being able to send video directly 
from a camcorder at home to the vcr/display at my parents house, to be 
able to turn up the thermostat in a winter vacation house before driving 
over there, and to be able to print on a printer at home when I'm on the road.
The key is how to secure this.

I think the above statement reflects this short-sighted resignation that we
as a communication don't know how to make usable security work for small
devices used by consumers.  But there is at least research on this
topic (using various imprinting techniques etc); for certain classes
of interaction I think usable security for small devices is not very far away.

Section 3.4: 
> If each endpoint has multiple addresses, the transport, middleware or
> application layer has the complex problem of choosing the correct pair
> of addresses to enable communication.  There are two conflicting goals
> here:
> 
> o To guarantee reachability between the endpoints.
> 
> o To ensure that the traffic stays within the tightest possible
>    administrative and security boundaries.

I don't seem to be able to understand the second bullet and its origin.
Perhaps it is just the "tightest possible" that is causing problems for me;
I think applications/middleware/etc might have some security requirements
themselves (whether expressable and expressed directly by those entities, or 
expressed separate e.g. as part of a corporate IT security policy),
but I don't see how "tightest possible" is security requirement that
fulfills a particular (business) objective.
Let me try to illustrate with an example:
A policy that makes some sense is "when in a company office do NFS in the
clear; when not in an office or using 802.11 in an office apply IPsec for NFS".
But a policy that says "make sure (cleartext) NFS traffic stays within the
tightest security boundary" means that when I'm in the IETF terminal room my
corporate NFS traffic travels unprotected; the tightest possible security
boundary encompasses the terminal room network and the Internet path back to
the corporation.

Can somebody try to enlighten me on what the second bullet is trying to say?

  Erik

_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad