Subject: Re: FYI: New ID submission- GRP

From: [email-masked]
Date: Thu, 8 Mar 2001 21:53:32 -0500

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

>        Wrong, security is a protocol thing as well.

And router discovery isnt a protocol that directly effects security..
Internet access does.... How do you design a router discovory protocol that
fixes a lack of host security?

>        Yes.  Router Discovery is the right answer
>if one wants to find a router.  It is widely deployed,
>works quite well, and is an IETF Standard.

Well, I'm glad to see that you feel there is a need to
discover routers now :-)

I'd like to talk about the technical specifics of GRP, etc..

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

>        That is a reference to IP Router Discovery,
>not some random loophole allowing arbitrary extensions
>to the scope of the ZeroConf WG.

How do you get that?

Spence

---

From: Erik Guttman <[email-masked]>
Date: Fri, 9 Mar 2001 20:46:51 +0100 (MET)

Spence,

The lack of reference to gateways in our charter is not a mistake.
When the WG was chartered we made the decision to work on protocols
for use within an non-configured, limited scope network.  Once these
networks grow to the point where these protocols are no longer 
appropriate, it is time to administer the network and add 
configuration.

> I'd like to talk about the technical specifics of GRP, etc..

There isn't much to say about it.

draft-giacalone-grp-00.txt:
>   By convention, Zero Configuration IP addresses are not permitted to
>   cross routed boundaries, and GRP does not violate this rule.

This is not convention - the v4LL draft states this as a protocol 
requirement.  Further, datagrams with a v4LL source address MUST
NOT be routed.  It isn't a question of IP addresses crossing boundaries,
its packets.

Please compare:

draft-giacalone-grp-00.txt:
>   The host portion of GRP includes:
>        -Discovery of GRP gateway routers
>        -Caching router response messages
>        -Monitoring GRP router keepalive messages
>        -Transitioning (failing over) to active gateway routers as
>         required

RFC 1256:
>  Hosts discover the addresses of their neighboring routers simply 
>  by listening for advertisements.  When a host attached to a multicast 
>  link starts up, it may multicast a Router Solicitation...

>  A Router Advertisement also includes a "lifetime" field, specifying
>  the maximum length of time that the advertised addresses are to be
>  considered as valid router addresses by hosts..

>  Any routers that subsequently start up, or that were not discovered 
>  because of packet loss or temporary link partitioning, are eventually
>  discovered by reception of their periodic (unsolicited) advertisements.

>  The Host Requirements -- Communication Layers RFC [1], Section
>  3.3.1.6, specifies that each host implementation must support a
>  configurable list of default router addresses.  The purpose of the
>  ICMP router discovery messages is to eliminate the need to configure
>  that list in hosts attached to multicast links.

draft-giacalone-grp-00.txt:
>   GRP operation on routers includes:
>        -Responding to GRP queries sent to the Zero Configuration GRP
>         router address.
>        -Originating GRP keepalive messages
>        -Properly handling the GRP keepalive messages originated by
>         other routers.
>        -Interoperation with NAT
 
Points 1-3 are covered by RFC 1256.  Point 4 is neither a requirement nor
desirable.

>>to the scope of the ZeroConf WG.

  The working group will also define how such a network may 
  automatically transition from 'configured' to 'unconfigured' 
  behavior, as well as from 'unconfigured' to 'configured'. 
  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, including DNS entries 
  supplied through standard DNS services. It is also possible 
  that both modes (ZEROCONF and administered) may coexist on the
  same network; the modes may not be exclusive of each other.

The same host may be using zeroconf protocols and configuration.
A host with a global address may still need to discover the
location of a router in order to 'be capable of direct IP
connectivity to the global Internet.'  We may end up recommending
implementation of RFC 1256, for example.  Currently it is an
ELECTIVE standard.

Currently the charter does *not* say that hosts with networks with
no configuration must be capable of direct IP connectivity to
the global Internet.  What you are hearing on the list is that
the rough consensus is that this is a *VERY BAD IDEA.*

The alternative - discussed already on the list - are ALGs and
authenticated access from remote hosts onto the zeroconf list
via a gateway.  Note that this is access ONTO the zeroconf network
from a host with a global address, security configuration and a 
notion of how to contact and authenticate with an application/
network layer gateway.

Erik

ps.  Please read draft-ietf-zeroconf-ipv4-linklocal-02.txt.  I
     quote the important paragraph below since it is so germane
     to the discussion:

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

>   This does not mean that link-local devices are forbidden from
>   communication outside the local link. IP hosts that implement both
>   link-local and conventional routable IP addresses may still use
>   their routable addresses without restriction as they do today.
>   Extremely simple IP devices that implement only link-local addresses
>   may also communicate with hosts outside the local link, provided that
>   such communication is mediated through a device capable of enforcing
>   appropriate security controls. For example, a home heating system
>   could be controlled via a Web server on the local network, where the
>   Web server uses cryptographic methods to verify the authority of the
>   remote user, and then uses link-local communication on the local
>   network to communicate commands to the heating system's thermostat.
>   Alternatively, a remote host could use a secure tunnelling protocol
>   to establish access to a 'virtual interface' on the local link, via
>   which it could then send and receive 'virtual' link-local packets
>   just like any other host directly connected to that link. It should
>   be understood that this mediated communication is not mandatory; it
>   is an option afforded to designers of very simple devices who wish to
>   implement only link-local addresses and thereby simplify their
>   security assumptions. Any designer of a device desiring unmediated
>   communication outside the local link need only implement today's
>   conventional IP host software (e.g. a DHCP client) in order to enjoy
>   the same degree of global addressability available to other
>   conventional IP hosts on the same network.