Subject: Re: FYI: New ID submission- GRP

From: [email-masked]
Date: Wed, 7 Mar 2001 21:06:05 -0500

> Although the intent of GRP is to allow hosts to get to
> gateway routers running NAT, GRP has nothing directly to do with NAT
> operation, IMHO.

The question is one of whether 169.254/16 will be allowed through ANY
gateway of any sort. There was quite a bit of discussion about this on
this mailing list in months past.

Relevant items include, in draft-ietf-zeroconf-ipv4-linklocal-02,
section 2.5:

   An IPv4 datagram whose source and/or destination addresses is in the
   169.254/16 range MUST NOT be sent to any router for forwarding, and
   any network device receiving such a datagram MUST NOT forward it,
   regardless of the TTL in the IP header.

NAT is a ROUTING function. The draft cited is the one which defines the
use of that address block, and we have a MUST NOT in the text there with
regards forwarding. I agree with that wording.

At first, the wording in the quoted text seems clear. However, if you plan
on translating an address, you dont plan to forward it, do you? Note the
wording "for forwarding". We do not plan for routers to forward- forwarding
means transiting a router, with the Zero Conf address intact, and as my
draft says, we dont plan to have anyone do that....

Not sure how you get that NAT is a routing function. It's a whole different
process, and it's a addressing service, not a routing one.

Using NAT, the source address that comes in on one side of the router, isnt
in the packet on the other side..... That means the address is not
forwarded...

Let me ask you something- Can you see inherently limiting a protocol to a
local network, never providing for the option of Internet access, being
healthy for a protocol's proliferation in this "day and age"? Will it be in
the future?

And later in that same section:

   The non-forwarding rule is important because it is expected that many
   link-local-only devices will be extremely simple devices of the kind
   that currently use X10 [X10], USB [USB] or FireWire [IEEE 1394].
   The designers of these devices assume that they will communicate
   only with other local devices, and implement a degree of security
   appropriate for that expected environment.

NAT devices are NOT simply private-address to public-address mappers,
employing NAPT (one public IP address). There are many variants of NAT,
and your proposal is in conflict with the sections of the linklocal
draft.

Okay, so what are the many variants of NAT, then? There are a few, not
many, but what's the difference, anyway?

The above quote is qualified in a number of ways, and is therefor open to
some interpretation:

1- it talks about some expectations- not all scenarios
2- it refers to a subset of very simple devices- not all devices
3- it refers to designers making security assumptions based on thier own
type of device and its specific usage. Firewire may not have the same needs
as a network of wireless attached PCs, right?

If you plan to attach a network or device to the Internet, you must plan
for security. Again, I'm not sure what you plan NOT to do in your Zero Conf
implimentation, but I would want mine to be as secure as any common IP
stack. Do you feel that as being reasonable?
>
> Dont you think that a properly secured Zero Conf net, with proper Zero
Conf
> implimentations is just as secure as an RFC 1918 (private IP) network
> running NAT?

Ummm, "properly configured zeroconf net"??? We're talking about nets
which do NOT need configuration!

Ummm, if you where to interconnect any network, it should like, be secure,
right? What I mean is you'd have a firewall protecting your whole network
wouldnt you? That has nothing to do with Zero Conf, right? Thats what I
mean.

Spence

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Wed, 7 Mar 2001 21:39:54 -0800 (GMT-0800)

> this mailing list in months past.

I vote "NO" on this. No forwarding. No NAT. No use in 6to4. About the 
only thing I can live with is an application layer gateway (e.g. home web 
portal secured by SSL).

---

From: Erik Guttman <[email-masked]>
Date: Thu, 8 Mar 2001 12:15:44 +0100 (MET)

> only thing I can live with is an application layer gateway (e.g. home web 

I completely agree with Bernard.  If remote access to the zeroconf
link-local network is desired, let it be through a secured gateway.

This could be an application layer gateway, or a secured tunnel.
An example of a secured tunnel would be a remote host using PPP,
which authenticates itself to a gateway.  Then, using a not-yet-
invented protocol, the remote host could obtain a link-local address 
on the zeroconf link, with mediation of the gateway.  

If I am not mistaken, this is similar to ideas Myron Hattig presented 
back at the second NITS BOF in 99.  We decided at that time that we 
would not attempt to charter work on secure remote access, though 
there was great interest in it (especially among 'home networking' 
vendors.)

Erik

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 8 Mar 2001 03:26:16 -0800 (PST)

> > I vote "NO" on this. No forwarding. No NAT.
    > 
    > I completely agree with Bernard.

<AOL> Me too!  Me too! </AOL>

    > on the zeroconf link, with mediation of the gateway.  

Uh, no magic neeeded here...  This is what all PPTP, L2F, L2TP, and IPSec
tunnel endpoints do right now, except that they typically assign local
addresses from a configured pool or by nabbing them from a DHCP server.
Unless I'm misunderstanding you.

                                -Bill