don@SRI-LEWIS.ARPA (Donald Holman) (12/15/87)
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