Subject: RE: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents

From: "Ken Larmer" <[email-masked]>
Date: Tue, 4 Sep 2001 15:50:20 -0400

Hi,

	I apologize upfront for the length of this memo. Though, I am still trying
to understand if we have a potential RFC-1195 protocol deficiency? I
discussed this issue with Mike offline and now we would like to get
everyone’s opinion on this “potential” deficiency.

	In summary, RFC-1195 Annex C Dijkstra Calculation treats IP Reachable
addresses as OSI End Systems. L2 LSPs do not contain OSI End System
advertisements, however, L2 LSPs do contain IP Reachable addresses. This
section applies the same Dijkstra calculations to OSI End Systems advertised
in L1 LSPs as is applied to IP Reachable addresses contained within L2 LSPs.
This yields a “potentially” undesirable result with reference to
calculations through an L1/L2 IS with a LSPDB overload condition.

	This is because OSI End System Entries are always considered to be directly
adjacent. Whereas L2 LSP IP Reachable address Entries are those, which are
adjacent and those, which may be determined from the level 1 LSPs from all
routers in the area. Of course, the IP Reachable addresses derived from the
L1 LSPs in the same area “MAY” not be directly adjacent to the L1/L2 IS
advertising these IP Reachable addresses in its L2 LSP.

	As a consequence, when we use the Dijkstra calculations outlined in
RFC-1195, Annex C, we calculate all L2 LSP IP Reachable address Entries as
being directly adjacent to an IS with a LSPDB overload condition. This “MAY”
result, given the correct configuration, in remote IS routers using an
overloaded L1/L2 IS, as a “transient” IS.

	I have verified this behavior with the following configuration:

(10.10.10.0) [A]<L1/L2>[B]<L1/L2>[C]<L1/L2>[D] (11.11.11.0)
                                    ^
                  LSPDB Overload condition

	All 4 IS routers (A,B,C,D) share a common area address (same L1 Sub-Domain)
and are also part of the same L2 Domain. IS-B has a LSPDB overload condition
and advertises this in its L1 and L2 LSPs by setting the LSPDB overload bit.
The other routers receive these LSPs and process them properly; they
calculate routes to directly attached destinations but do not use IS-B as a
transient IS. The problem is that an IP host connected to subnet 11.11.11.0
can still reach subnet 10.10.10.0. This is made possible because IS-B is
advertising, in it's L2 LSP, the contents specified in RFC-1195 Section 5.2.
As a consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be
reachable via L2 routing, because they think IS-B has a direct connection to
this subnet. Conversely, IS-A calculates IP subnet 11.11.11.0 to be
reachable via L2 routing, because they think IS-B has a direct connection to
this subnet.

	Now let’s say each link has a metric = 10. IS-B is advertising L2
reachability to IP subnet 10.10.10.0 with a metric = 20.  IS-C and IS-D
install an L2 IP route in their routing table to IP subnet 10.10.10.0 via
their next hop to IS-B. IS-B possesses an L1 IP route to IP subnet
10.10.10.0 via IS-A. So IS-B installs a L1 IP route to 10.10.10.0 in its IP
routing table. Conversely, IS-A possesses a L2 IP route to IP subnet
11.11.11.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 11.11.11.0
via IS-C...

	Consequently, we possess an IP route from IS-D (subnet 11.11.11.0) to IS-A
(subnet 10.10.10.0), which uses the following path. Source = IS-D and
Destination = IS-A. IS-D forwards the IP packet to IS-C via L1, IS-C
forwards the IP packet to IS-B via L1 and then IS-B forwards the IP packet
to IS-A via L1.

	I believe that the above translates into a possible back-door path through
a L1/L2 IS, which is in the overload condition. I can think of the following
conditions for which this behavior “MAY” have a negative impact, these
configurations have “NOT” all been verified.

1. The LSPDB OLV bit may be set manually in most IS-IS implementations and
can be used by ISPs as a mechanism for testing new or updated
implementations of IS-IS in their backbones. I suspect, this is most often
accomplished by either placing an IS DUT in a STUB area or in parallel with
an active IS. The stub scenario will still work fine, however, the parallel
configuration “MAY” mean that the IS DUT will be used as a transient IS?

2. The LSPDB OLV bit may be set on restart and then cleared on some
condition (timer or synchronization with another IGP or EGP). If the IS in
question were to generate new LSPs prior to receiving all of its routes,
this “MAY” cause this IS to be used as a transient IS, even though it may
not possess all of the routing information it needs to make the correct
forwarding decisions?

3.  When the LSPDB OLV bit is set as a result of an actual LSPDB overload
condition, with a similar configuration as I originally outlined, this will
cause the IS to be used as a transient IS. Depending on the exact cause of
the LSPDB overload condition, this may cause IP packets to be forwarded to
incorrect destinations. Consequently, a black hole “MAY” appear in the
network?

4. When a router configured as an LSP flooding server, e.g. on an NBMA
network, in combination with the mesh-group feature. This “MAY” allow access
to the NBMA network prior to complete synchronization?

5. When a router that is aggregating VCs used only for network management.
In this case, the network management stations must be on a network directly
connected to the router with the set-overload-bit command configured. This
allows all of the local network management stations to have complete access
to the entire network through the IS with the OVL bit set. This is because
they are not going through another IS first to get through this IS with the
OVL bit set. The IS routers connected to the remote side of the VCs, more
than likely, possess network management IP addresses, which are associated
with a particular loopback interface on that IS. ACLs may be configured to
only allow SNMP or CLI access to users who connect to this loopback
interface IP address. Because these loopback interfaces are 1 hop away
(non-adjacent IP subnets), other IS routers in the domain will have
connectivity to these IS management capabilities. This “MAY” break an ISPs
network security scheme for router management?

Proposed resolution:

RFC-1195 currently states:

	L2 LSP

	IP Internal Reachability Information -- IP addresses within the routing
	domain reachable directly via one or more interfaces on this Intermediate
system.

Proposed Change to RFC-1195

	Begin:

	L2 LSP

	If source systemID, LSP number = 0, LSPDB OVL = 0;

	IP Internal Reachability Information -- IP addresses within the routing
	domain reachable directly via one or more interfaces on this Intermediate
	system.

	Otherwise;

	IP Internal Reachability Information -- IP addresses directly attached to
	one or more interfaces on this Intermediate system.

	End:

	The above suggestion should fix these “potential” problems because only
directly attached IP subnets will be advertised in L2 LSPs when an LSPDB
overload condition is detected. Besides, under actual LSPDB overload
conditions, do we really want to advertise information, which “MAY” be based
on incomplete LSPDBs?

Cheers,
Ken Larmer

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg