Re: [Isis-wg] WG LC draft-ietf-isis-purge-tlv-03.txt

[Tony Li <[e-mail]>]

Hi Les,

> The companion text to this in RFC 5304 is:
> 
> "ISes (routers) that implement HMAC-MD5 authentication and initiate LSP
>   purges MUST remove the body of the LSP and add the authentication
>   TLV."
> 
> Clearly the combination of the two leaves no wiggle room as the behavior
> of both the purge initiator and the purge receiver is strictly
> specified.
> 
> One does wonder however whether all implementations were this strict in
> their receiving code. It is conceivable that an implementation could
> apply the authentication logic to a received purged LSP in the same
> manner that it would to a non-purged LSP - in which case it would simply
> apply authentication to the body (if it exists). This would be in
> violation of the above provisions in RFC 5304 - but might reasonably be
> done in the spirit of being "strict in what you send but generous in
> what you receive".


True, but there is rationale behind the text in 5304.  If implementations are relaxed about the purges that they accept, then an attacker can simply take any LSP, set the remaining lifetime to zero, and flood it, complete with authentication.

The whole point of the text is that to authenticate a purge, the IS initiating the purge MUST remove the body of the LSP (or somehow change it) and then re-authenticate it.

So there is method to the madness.


> In any case what is deployed is beyond our ability to change, so perhaps
> the best we can say is:
> 
> "Use of the extensions defined here with authentication as defined in
> RFC5304 or RFC5310 will result in the discarding of purges by legacy
> systems which are in strict conformance with either of those RFCs. This
> may compromise the correctness/consistency of the routing database
> unless all ISs in the network support these extensions. In cases where
> the purge is initiated by owner of the LSP the problem may be avoided by
> first generating a non-purged version of the LSP with no body."
> 
> ???


Yes, we could say that, but in fact 2002 says pretty much the opposite:

   7.3.4.6 If an LSP becomes empty, because all of the adjacencies reported 
   in that LSP no longer exist, it is recommended that an IS purge that LSP. 
   An IS may alternatively choose to reissue it as an empty LSP (i.e. with no 
   options), although purging is preferable. An IS should not allow the LSP to age 
   out as this results in having incorrect routing information in all of the LSP 
   databases.

[Aside: as a matter of protocol design, it probably would have been better to consistently issue empty LSPs and subsequently have them age out rather than to create the independent purge mechanism.  Fewer mechanisms and less room for abuse.]

Tony