Subject: Re: FYI: New ID submission- GRP

From: [email-masked]
Date: Tue, 6 Mar 2001 22:19:53 -0500

Comments inline:

Spencer Giacalone, Predictive Systems
---------------------------------------------------------------
"Nothing so much prevents our being natural 
as the desire to seem so" -Francois, Duc de 
La Rochefoucauld

Daniel Senie <[email-masked]>
Sent by: [email-masked]
03/06/01 05:20 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: FYI: New ID submission- GRP

[email-masked] wrote:
> 
> Why do you want to reinvent this mechanism?
> 
> GRP is more simple and automatic than ICMP Router Discovery. It is not
> tied to any other protocol (other than ARP), does not rely on multicast,
> does not assume support for outside "black hole" detection, does not
> require configuration of a host based router query address, does not
> define new packet types, does not include complex preference schemes
> (which one can argue won't be needed in Zero Conf nets), provides
> incorporated "black hole detection" and permits configuration-less dead
> interval detection on hosts. For these reasons (simplicity and
> automation), we feel that GRP is more closely aligned with the goals and
> spirit of Zero Conf. It is not our goal to argue the religious aspects 
of
> GRP, ICMP-RD or any other gateway discovery protocol.

Your I-D submission made no mention of ICMP Router Discovery. Further,
it had only ONE citation of any sort.

We aren't going to site things we didn't take from, or quote. That's how 
you do it. 

 You might want to rewrite your
draft to include your reasoning for inventing a new mechanism, and why
you believe it is necessary in the face of similar technology which is

I can do this in the next rev. That's why they are posted, and the list 
discusses them. 

(and I think you missed this in my comments) already implemented in
hosts and routers today. 

Can you restate your question then? I think I gave some direct answers. 

> 
> Your suggested
> approach is completely tied to the 169.254/16 address block,
> 
> We are not tied to any address or block. The suggested use of a single,
> well known GRP address permits configuration-less gateway router 
discovery
> by hosts. The address could be changed if that was needed. Furthermore,
> since we can assume what the subnet and prefix will be, GRP should not
> have to wait for the host's interface address to be determined before
> processing "protocol" packets. Note that we also assume that the only 
time
> the GRP router address is directly used (not reading ARPs)is during
> host-gateway query.

> 
> and doesn't
> provide any advantage over a protocol already understood by hosts and
> routers.
> 
> GRP does not loose functionality to ICMP-RD, but has advantages, see 
above

Overall, you've proposed we use NAT, which has been widely implemented
in routers, but do so without DHCP, which also is present in nearly
every NAT device on the market,

Which I made a very clear case AGAINST in my draft (DHCP). NAT does not 
equal DHCP. Where do you get that? 

 and create a new router discovery
protocol which requires every client system and stack to be altered. I
wonder why implementers would like this approach over using an existing,
off-the-shelf $120 NAT/DHCP box, and having existing machines just
function? What's gained by all this extra work? You don't give enough
arguments in your I-D to understand why your approach is compelling.
This is just my opinion, of course. Other WG members may see it
completely differently.

Please thoroughly read the arguments I made against DHCP. 

Spence

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: [email-masked]
Date: Wed, 7 Mar 2001 06:36:59 -0500

"Bernard Aboba" <[email-masked]>
03/07/01 02:58 AM

        To:     "Daniel Senie" <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: FYI: New ID submission- GRP

And it also begs the question of why a host with a linklocal
address should be able to "reach the Internet". Isn't the whole
idea of linklocal addressing to avoid forwarding off link??

I think that's covered in the draft- although it's more of a philosophical 
question that a technical one. Is it really logical (or possible) for us 
to assume what will or wont be connected to the Internet in the future? 

Spence

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Daniel Senie
Sent: Monday, March 05, 2001 6:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: FYI: New ID submission- GRP

It appears to me you've reinvented router discovery protocol. See RFC
1256. Router discovery has been around for quite some time, and works
fine. Why do you want to reinvent this mechanism? Your suggested
approach is completely tied to the 169.254/16 address block, and doesn't
provide any advantage over a protocol already understood by hosts and
routers.

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 8 Mar 2001 12:24:12 -0800

Hi,

I agree completely with Bernard and Erik.

NO forwarding off a 'link-local' subnet.  Secure application
layer gateways are reasonable to consider.  'Magic' via NAT
is NOT reasonable to consider.

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:16 AM
To: Bernard D. Aboba
Cc: [email-masked]; Daniel Senie; [email-masked]
Subject: Re: FYI: New ID submission- GRP

> > 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.
> 
> 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). 
> 

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: [email-masked]
Date: Thu, 8 Mar 2001 15:36:56 -0500

Again, GRP does not equal NAT. It's about getting to a gateway.

Spence

     To:  "'Erik Guttman'" <[email-masked]>, "Bernard D. Aboba"
<[email-masked]>
     cc:  [email-masked], Daniel Senie <[email-masked]>,
[email-masked]
     bcc:
     Subject:  RE: FYI: New ID submission- GRP
"McDonald, Ira" <[email-masked]>

03/08/2001 12:24 PM PST
          <font size=-1></font>

Hi,

Cheers,

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:16 AM
To: Bernard D. Aboba
Cc: [email-masked]; Daniel Senie; [email-masked]
Subject: Re: FYI: New ID submission- GRP

Erik

---

From: [email-masked]
Date: Thu, 8 Mar 2001 16:06:49 -0500

Ran,

What is the trend? That we dont like NAT, or that Zero Conf will be forever
limited to local nets (which IMHO would be a very bad thing for this
protocol's future)? There seem to be two arguments being made, not one
trend.

If the prior, than you just dont like NAT, and the wording in the GRP draft
can change..

Spence

     To:  [email-masked]
     cc:  [email-masked]
     bcc:
     Subject:  RE: FYI: New ID submission- GRP
RJ Atkinson <[email-masked]>

03/08/2001 03:59 PM
          <font size=-1></font>

>Again, GRP does not equal NAT. It's about getting to a gateway.

Spencer,

I don't care.   I still agree with Bernard and Erik.  I'm not
the WG chair, but there IS a trend here in the list comments
about this topic...

Lets drop GRP and move on.

Ran

---

From: [email-masked]
Date: Thu, 8 Mar 2001 18:33:05 -0500

> You talking about NAT, and whether you can live with it. GRP is about how
> to get to a gateway. Maybe it's running NAT, maybe it's an application
> layer gateway.

>The application layer gateway should be located via service location,
>which is discussed in the zeroconf requirements document. I believe
>that'd be the best way to find an appropriate application gateway path
>for a particular need or service.

Many protocols for service discovory are not complete solutions becouse
once a service is found, one still needs to know how to connect to the
device providing the service. Where does the requirments doc say what the
service discovory protocol will do? Where does it say that it will do more
than say that the service is availiable? What if that device is not on the
Zero Conf net?

Do a search on the requirments doc on the word gateway. It's not even
there.

>there may be many
>application gateways carrying application data (hopefully secured) on
>and off the LAN.

That'll make for an interesting design. I'm sure network managers will love
that.

>They may be providing different types of information to
>different outside players.

I'm not sure what type of topology you are considering, but if it's a
secure one, than it looks like a VPN or VPNs.. People may not want to be
limited in that way..

>Security is a big part of the reason for this stance. At a minimum, you
>need to add the required security considerations section to your draft.
>As you talk of a special code point use (an address), an IANA
>considerations section should also be present.

As far as security goes, how about section 3 in the requirments draft?
Going back to how secure Zero Conf hosts should be:

"implementations should
   strive to be "secure out of the box" and have a safe default
   configuration.

   Zeroconf protocols MUST NOT be any less secure than related
   current IETF-Standard protocols. This consideration overrides the
   goal of allowing systems to obtain configuration automatically. "

It's not a GRP thing, it's a host thing..

>Should we need to find gateways by
>other means, we do have ICMP Router Discovery which could be employed,
>though I hope we won't need to use it. It's not clear we need gateway
>location protocol to find our way around 169.254/16.

I think we have covered this, early in this thread.

>The zeroconf requirements document gives the requirements for the
>service location protocol.

That does not mean that a gateway location protocol should be ignored. One
could argue that a service in the context that the requirments draft talks
about them, is not a gateway function, which lies below services, like
printing, and "even
     perhaps requesting delivery of a pizza." as in section 2.4 of the
draft.

>You'll
>note, however, that the preset goals of the working group include only a
>scoping of the problem, plus formal definition of the link-local address
>space and a similar specification for multicast.

About the Charter:

"The ZEROCONF WG will precisely define the requirements for each of the
following functions:

* Interface Configuration (IP address, network prefix, gateway router)"

So gateway functions are included..

And:

"That is, the same hosts must be able to function on networks with no
configuration as well as be capable of direct IP connectivity to the global
Internet,"

So, Internet access is in, and no mention of App Layer gatewaying..

And:

"When ZEROCONF networks or hosts which are configured using ZEROCONF
protocols are connected to the big 'I' internet, they should not
automatically become vulnerable to new security threats. "

So, again the "big I" is in, and the burdon of security is on the
implimentation. No mention of App gateways, no stopping the use of NAT..