Subject: [Isis-wg] Comments on draft-ietf-isis-hmac-03.txt

From: Les Ginsberg <[email-masked]>
Date: Wed, 24 Apr 2002 16:11:52 -0700

Section 2.1 of "draft-ietf-isis-hmac-03.txt" discusses a problem associated
with password rollover immediately preceeding a router restart. If the
restarted router has not yet regenerated and propagated its own LSPs based
on the new password configuration then the restarted router is not able
to accept its own stale LSPs as propagated by its neighbors and would
therefore not increase the sequence # of its locally generated LSPs to
allow other routers to recognize these copies as "newer".

The draft suggests that an implementation cautiously accept the
LSPs which fail authentication if these LSPs have the local system ID
in the first portion of the LSPID field AND have a higher sequence
number than the local copy. The authors admit this leaves the system open
to replay attacks.

Text below discusses alternative solutions to the problem which present
no backwards compatibility problems and eliminate the need for bypassing
authentication. We propose that the solutions be incorporated into a revised
version of the draft.

  Les Ginsberg/Satish Dattatri

--------------------------------------------------

The likelihood of this problem occurring is significantly reduced by
proper implementation of a Defect Report against ISO 10589 filed in
April 1993. At that time it was noted that:

  "While ISO 10589 adequately covers all the conditions for processing
   received LSPs and determining whether a received LSP is
   newer than an LSP already stored by an IS, the same level
   of description is not available for the processing of SNPs.
   The intention is that the same procedures apply to SNPs as
   to LSPs, but this is not explicitly stated in the applicable
   clause(7.3.15.2)."

The remedy for this omission is to apply the description
of LSP confusion(7.3.16.2) and Remaining Lifetime(7.3.16.3) to the
processing of SNPs. The textual changes have been incorporated into
ISO 10589:2001 (see 7.3.16.2, 7.3.16.3, and 7.3.15.2b).

Most relevant to the issue raised in Section 2.1 of the draft is
to note that if an IS receives an SNP entry which specifies an LSP
generated by the local system which is newer than the local copy,
it must regenerate its local copy with a sequence number one greater
than that in the corresponding SNP entry. Since the SNP contains
current authentication it is accepted and all SNP entries it contains
are processed. This means that in most scenarios the problem
described in the draft is resolved by the normal exchange of CSNPs following
Pt-Pt adjacency establishment and the processing of periodic CSNPs
from the DIS on a LAN.

A few "corner cases" remain:

Case 1:
If the restarted router becomes the DIS on a LAN, it will generate,
not receive, periodic CSNPs. Systems which have a stale LSP generated
by a previous incarnation of the restarted system will respond to
the corresponding SNP entry by sending that stale LSP onto the LAN.

Case 2:
If the link layer on a Pt-Pt circuit does not provide reliable delivery,
then it is possible for one or more of the initial CSNPs to be lost. In
this case the restarted router may never receive an SNP entry for
one or more stale LSPs.

Case 3:
On a Pt-Pt circuit a stale LSP may arrive at
a neighbor from some other IS (not a neighbor of the restarted router)
shortly after the exchange of initial CSNPs. This LSP will never
be seen by the restarted router as an entry in a CSNP.

(Note: Periodic CSNPs will overcome cases 2 and 3, but periodic CSNPs
are not required on a Pt-Pt circuit.)

In all of these cases, the stale LSPs will be sent by neighbors of
the restarted router but will be ignored by the restarted router
due to authentication failure. Two solutions are available to resolve
these cases without the need to bypass authentication checks.

Solution #1:

The rules for processing a received LSP generated by some other
system which is "older" than the local copy, as described in 
7.3.15.1e)3) of ISO 10589:1992 must be amended as follows:

 "If the (received)LSP is older than the one in the database
  and the copy in the database contains Authentication
  Information then a recheck of the authentication information
  shall be performed. If this check fails, the Remaining
  Lifetime in the local copy shall be set to 0 and the actions
  described in 7.3.16.4 shall be taken. Otherwise Set SRMflag for C
  and Clear SSNflag for C"

Similarly, the rules for processing a received SNP entry which describe
an LSP older than the one in the local database, as described in
7.3.15.2b)2) of ISO 10589:1992 must be amended as follows:

 "If the reported value is older than the database value
  and the LSP source is some other system and the copy in the
  database contains Authentication Information then a recheck
  of the authentication information shall be performed. If this
  check fails, the Remaining Lifetime in the local copy shall be
  set to 0 and the actions described in 7.3.16.4 shall be taken.
  Otherwise Set SRMflag for C and Clear SSNflag for C"

Solution #2:

When a router restarts and authentication is enabled locally at the
corresponding level, the router assigns itself a temporary LAN priority of
0,
making it the least likely system to be elected DIS. This temporary priority
shall be maintained until a complete set of CSNPs has been received and
no SRMflags have been set on that circuit for any local LSPs which were
reported in that set of CSNPs. (NOTE: If all systems on the LAN are set
to priority 0 then it is still possible for the restarted router to be
elected DIS - so this solution is not bullet-proof.)

Discussion:

Solution #1 requires routers to recheck authentication on the LSP
copy in their database in the
event they receive an LSP/SNP entry for an LSP generated by another
system and is OLDER than the one in the local database. If the
authentication
recheck fails the LSP is purged. Since the system is required to insert
current authentication information when purging an LSP, this resolves the
problem without requiring the system to be vulnerable to replay attacks.
(It is important to note that when purging an LSP a router must always
include authentication information based on the current local 
password configuration.)

Solution #1 addresses all problem cases noted above. But until
all routers implement solution #1, there is some possibility that
some of the problem cases identified above may not be resolved.
Of the three mentioned, Case #1 is the most likely to happen.
Solution # 2 is offered to handle that case. Cases #2 and #3
are very unlikely to occur. If they do occur, then LSP DB synchronization
will be incomplete until all stale LSPs age out. The possibility of
this occurring exists in current networks i.e. this problem has not been
introduced by the HMAC extension - it can occur using plain text
passwords as well. Accepting the low probability
of the occurence of Problems #2 and #3 (until all routers can be
upgraded to support Solution #1) may be preferable to bypassing
authentication. However, network administrators may still prefer to
have a knob which bypasses password authentication for locally
generated LSPs so as to be able to overcome the rare instance when the
extensions to the protocol are insufficient. The period of time this
knob is enabled should be minimized so as to minimize risk to the
network.

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