Final comments, Rabid Bite.


Donald Holman (don@sri-lewis.arpa)
Mon, 14 Dec 87 10:13:17 PST


To the collective body:

I recently sent a note out requesting information on a few (4)
items of interest which appeared to lack a clear standard solution.
These were SLIP Link establishment, setting the security bit in
the IP header, routing metric determination and DDN Leased lines.
Below is a summary of the several comments I received pertaining
to all but DDN Leased lines.

1) SLIP LINK ESTABLISHMENT

Comment summary:
---------------------
From: Charles Hedrick alias hedrick@athos.rutgers.edu
        - About routing. Most protocols allow the system administrator to set
          the link cost. Even RIP now allows this. The algorithm is still
          the same as min hop, but you can in effect simulate a certain line
          counting as more than one hop. This lets you take into account
          cost, line speed, or whatever. DECnet has been doing this for
          years, as have various similar protocols.
From: Bill Graves alias Graves@mathcom.cisco.com
        - cisco Systems has developed a SLIP server which performs
          negotiation for IP addresses. This server is presently
          in alpha test and is being prepared for shipping as a
          standard feature of their terminal servers.
From: James B. VanBokkelen alias JBVB@AI.AI.MIT.EDU
        - there was interest expressed in a Birds Ofa Feather session
          hospitality suite in just this issue. This BOF consisted of
          considerable discussion of what to do next, and there were some
          basic agreements reached regarding direction and basic structure.
          There is a new mailing list being formed to discuss /evolve/resolve
          serial lines and dialup IP.
From: Russ Hoby alias ccruss@deneb.ucdavis.edu
        - The BOF was too large to get any protocol work done, however
          various input was received with regard to potential uses of SLIP.
          One use is the connection of isolated computers without access to
          a LAN. The second is SLIP in support of temporary network links.
          Some work was done toward and RFC, this is what was covered:
             1) The RFC will cover both connection and line protocols
             2) Connection specifications will cover negotiation of items such
             as network addresses, authentication, line speed, compression
             used, and probably other items.
             3) The line protocol will contain one byte in the header to
             indicate the protocol in the packet. This allows the use of line
             control packets for maintaining the serial link, as well as
             allowing other protocols in addition to IP and the line control
             to use the connection.
From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU
        - There was an extensive session at the "High Speed SLIP"
          demonstration at which an upgraded SLIP was designed.
          I believe that Drew Perkins (ddp+@Andrew.CMU.EDU) is going
          to write up an RFC for it.

MY COMMENTS (for what they are worth):
        I missed the BOF session, and thus am not well read-in on
        what specifically has been proposed or what was considered
        for the RFC. Can I get more information on what was discussed?
        I am interested in the IP address validation & data compression
        techniques and the general content of the RFC. I would appreciate
        anything that is passed in my direction pertaining to SLIP.

2) SETTING THE IP SECURITY OPTION

Comment summary:
---------------------
From: Bill Graves alias Graves@mathcom.cisco.com
        - This is probably a key management issues and should be referred
          to the appropriate government agency as they are the only ones
          able to authorize the setting of this bit.
From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU
        - The problem is that if you let the application set it arbitrarily,
          then it doesn't offer security (everybody just turns it on),
          it needs to be connected with some security mechanism in the
          hosts, and you have to trust the security of ALL the hosts.
From: John A. Shriver alias jas@monk.proteon.com
        - Our security features (in the p4200) do NOT depend on the IP
        security option. They depend on origins and destinations. You specify
        two masks, two results, and a sense. The source and destination are
        and-ed with the appropriate mask (a 32-bit integer). This is then
        compared to the results. If both results match, the packet is (or is
        not) forwarded as per the sense. This appeared to be as
        all-encompassingly flexible as we could imagine without being
        lethal to performance.

MY COMMENTS (for what they are worth):
        Since there will be a real security requirement sooner than
        most would like, this is something that should be resolved ASAP.
        I agree that there are some real headaches when one begins to
        consider security. I tend to believe that the upper layer
        protocols MUST have the mechanics for passing this information to
        the network layer (anyone done this?). I realize the implications
        of adding this to the the upper layers, but if the IP security bit
        is the way to go the setting of the bit has to be supported.
        I agree that as soon as this is supported that every hacker
        and their brother will be TRYING to use this as a way of
        breaking into a secure system. It seems to me that this bit
        (in the IP header) is not really for security but is to assist
        in the routing and or discrimination of the datagram.
        The only real security might be network isolation via some
        form of encryption.

3) ROUTING METRICS.

Comment summary:
---------------------
From: Bill Graves alias Graves@mathcom.cisco.com
        - Routing metrics are an exceedingly complex set of issues and
          cannot be effectively addressed in this message.
From: Paul F. Tsuchiya alias tsuchiya@gateway.mitre.org
        - The techniques for routing with something more sophisticated than
          hop-count are well known. ARPANET uses a delay calculation which
          many people, including myself, believe is over-kill in the sense
          that the filtering required on the delay measurements to avoid
          oscillations wipes out most of the benefit gained. The current
          IS-IS (gateway to gateway) routing proposal in ISO uses a static
          value that can mean anything the system administrator wants. It
          usually is related to the bandwidth of the link. The IS-IS protocol
          uses this value in its update messages if the link is up, or
          declares it down otherwise. Finally, BBN has done a fair amount
          of work in the area of multiple metrics (Type of Service routing).
From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU
        - cisco systems uses a much more elaborate scheme (I believe it's a five
          dimensional metric, and hop count isn't one of them).
From: Ross Callon alias rcallon@PARK-STREET.BBN.COM
        - The BBN Butterfly gateways do NOT use a simple hop count
          for routing decisions, for essentially the reason that you
          gave. Instead we use a cost which is administratively set as
          a function of the network characteristics. The IS to IS routing
          proposal being developed by the X3S3.3 folks also uses
          administratively set costs. BBN is intending to publish
          a description of their SPF, while there is a semi available
          version of the ANSI proposal.
From: John A. Shriver alias jas@monk.proteon.com
        - DECnet uses cost as a metric of goodness. They also keep a hop
          count, but this exists SOLELY to implement the count-to-infinity
          speedup on the routing loops that form in broadcast routing protocols
          when a node goes away. The same logic exists in the ANSI IS-IS
          proposal to ISO, which is essentially DECnet Phase V.

MY COMMENTS (for what they are worth):
        It seems to me that (simply stated) if the best
        route can be determined the best route should be used. I
        don't argue with the complexity of determining the best route.
        I am minimally aware of the five determining factors which cisco
        Systems uses in route selection (from what I know of this five
        factor method it seems sound, it would be nice if it had broader
        support thru the community). I guess that the best of
        all worlds would be nice, what about a standard? To be capable
        of garnishing the route determination with a mix of all information
        available would be the best way to go as long as looping is avoided
        and the overhead of doing so is not a burden. It would seem to me that
        6 or 7 of the items mentioned below would be good input for route
        selection, but then again I have not considered this for long and may
        be in left field.

                MINIMUM_HOP
                BANDWIDTH
                MINIMUM_DELAY
                MINIMUM_MTU
                FRAGMENTATION_REQUIRED
                RELIABILITY
                ADMINISTRATIVE DISTANCE

        I will looking forward to any published information on routing
        algorithms (hope it becomes available to the general public soon).

Thanks for the time spent on responses!

The thoughts and comments within, unless specified, are my own.

TIA,
Don



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:58 GMT