Subject: [dhcwg] Proposed Resolution to DNA Issue 28: Silent RIP & OSPF

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Jun 2005 17:30:23 -0700 (PDT)

Sam Hartman has filed an Issue during the IESG review of DNAv4.  The issue
is enclosed below.

The proposed resolution is as follows:

In Section 2.1, delete the following paragraphs:

"  Aside from utilizing link layer indications, a host may also be able
   to utilize Internet layer information in order to determine the MLAN.
   IPv4 ICMP Router Discovery messages [RFC1256] provide information
   relating to prefix(es) available on the link, as well as the routers
   that serve those prefix(es).  A host may use ICMP Router Discovery to
   conclude that an advertised prefix is available; however it cannot
   conclude the converse -- that prefixes not advertised are
   unavailable.

   However, since [RFC1256] is not widely implemented, it is NOT
   RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
   alternative to the reachability test outlined in Section 2.2.
   Instead, ICMP Router Advertisements can be used to obtain information
   on available prefixes and default gateway(s).  This can provide
   additional resilience in the case where default gateway(s) become
   unavailable.

   Similarly hosts that support routing protocols such as RIP and OSPF
   can use these protocols to determine the prefix(es) available on a
   link and the default gateway(s) that serve those prefixes.  Full
   support is not required to glean this information.  A host that
   passively observes routing protocol traffic may deduce this
   information without supporting a fully conformant routing protocol
   implementation."

Add the following Section A.3 to Appendix A:

"A.3 Internet Layer Hints

Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLAN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.

However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become
unavailable.

Similarly hosts that support routing protocols such as RIP [RFC2453]
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation. For a description of "Silent RIP", see [RFC1058]
Section 3.1."

Add the following references:

[RFC2453]  Malkin., G., "RIP Version 2", RFC 2453, STD 56, November 1998.

[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,  June
1988.

---------------------------------------------------------------------------
Issue 28: Silent RIP & OSPF
Submitter name: Sam Hartman
Submitter email address: [email-masked]
Date first submitted: June 21, 2005
Reference:
Document: DNA-12
Comment type: T(echnical)
Priority: S
Section: 2.1
Rationale/Explanation of issue:

Section 2.1 of the document discusses implementations of DNAV4 using
snooping versions of OSPF and RIP to understand what prefixes are on a
subnet without fully participating in a routing protocol.  While this
practice is encouraged by this specification, no reference to how to
do it is provided.  If such a reference exists it needs to be
included.  If no such reference exists, please confirm that sufficient
detail is provided that implementations are unlikely to break the
routing infrastructure by mis-implementing this feature.

[Margaret Wasserman]

Sam and I discussed this issue, and he asked whether this issue had been
discussed in the WG.

I don't remember that it has, so I encouraged him to hold a discuss while
we discuss this...

Currently section 2.1 says:

   Similarly hosts that support routing protocols such as RIP and OSPF
   can use these protocols to determine the prefix(es) available on a
   link and the default gateway(s) that serve those prefixes.  Full
   support is not required to glean this information.  A host that
   passively observes routing protocol traffic may deduce this
   information without supporting a fully conformant routing protocol
   implementation.

I know that snooping versions of RIP and OSPF are widely implemented and I
(think I) know what subsets are needed for this "passive observer"
functionality.  This is trivial in RIP (you can literally act as a passive
observer on the RIP port), but a bit more complicated in OSPF, where (if I
understand correctly) you will have to associate with neighboring OSPF
routers to receive routing information, while not publishing any routes
yourself.  I don't think that you can snoop OSPF information while being
entirely passive, can you?

Anyway, if there is a reference for how to snoop using OSPF or RIP, that
would be best.  But, if there is not a reference, do you think that we
need to say a bit more in section 2.1 about what subsets of RIP and/or
OSPF are needed to do this?

As a minor editorial side note, you should probably include references for
RIP and OSPF.

[Bernard Aboba]

Silent RIP is discussed in RFC 1058, Section 3.1:

"   There are provisions in the protocol to allow "silent" RIP processes.
   A silent process is one that normally does not send out any messages.
   However, it listens to messages sent by others.  A silent RIP might
   be used by hosts that do not act as gateways, but wish to listen to
   routing updates in order to monitor local gateways and to keep their
   internal routing tables up to date.  (See [5] for a discussion of
   various ways that hosts can keep track of network topology.)  A
   gateway that has lost contact with all but one of its networks might
   choose to become silent, since it is effectively no longer a gateway."

Silent RIP has been widely implemented.  See:

http://www.unix.org.ua/gated/node25.html

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/79408f3f-d8fc-4c4b-9ede-dc85fabd5b2e.mspx

After searching the OSPF RFCs, I could not find a mention of "silent
OSPF".

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg