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

From: David Ward <[email-masked]>
Date: Thu, 12 Aug 2010 09:00:38 -0700

Dear WG -

	We'd like to start a WG LC on this draft:

http://www.ietf.org/id/draft-ietf-isis-purge-tlv-03.txt

Please reply to the WG list and authors with any clarifications, questions or comments. The comment period will end 2010.08.27 at 1700 PDT.

Thanks

-DWard, CHopps

---

From: Minto Jeyananth <[email-masked]>
Date: Thu, 12 Aug 2010 09:33:53 -0700

I have one major comment. 

5.  Security Considerations
<snip>
   Legacy systems that implement [RFC5304] or [RFC5310] MUST discard
   purges with these additional TLVs.  This is not thought to be a
   significant operational issue as the loss of purges is typically not
   critical.

If IS purges its own LSP (because all of IP prefixes reported in that LSP no longer reachable) then every IS (including the legacy systems) need purge it. 
 
Thanks 
-minto 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf
|Of David Ward
|Sent: Thursday, August 12, 2010 9:01 AM
|To: isis mailing list; [email-masked]; [email-masked];
|???; Tony Li; [email-masked]
|Cc: Adrian Farrel; Christian Hopps
|Subject: [Isis-wg] WG LC draft-ietf-isis-purge-tlv-03.txt
|
|Dear WG -
|
|	We'd like to start a WG LC on this draft:
|
|http://www.ietf.org/id/draft-ietf-isis-purge-tlv-03.txt
|
|Please reply to the WG list and authors with any clarifications, questions
|or comments. The comment period will end 2010.08.27 at 1700 PDT.
|
|Thanks
|
|-DWard, CHopps
|_______________________________________________
|Isis-wg mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Aug 2010 11:33:33 -0700

> If IS purges its own LSP (because all of IP prefixes reported in that LSP no longer reachable) then every IS (including the legacy systems) need purge it. 

Thank you for your comment.  This is an excellent point.  Unfortunately, RFC 5304 says:

   ISes MUST NOT accept purges that contain
   TLVs other than the authentication TLV.

RFC 5310 does not address the topic of authenticating purges, which is a significant flaw in that document.

I see no obvious way of addressing this other than instituting a flag day for the introduction of the Purge Originator Identification TLV.  Does anyone see a better solution?

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Aug 2010 11:54:24 -0700

Tony -

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tony Li
> Sent: Thursday, August 12, 2010 11:34 AM
> To: Minto Jeyananth
> Cc: isis mailing list; [email-masked]; Adrian Farrel; Chris
> Hopps (chopps); ???; [email-masked]
> Subject: Re: [Isis-wg] WG LC draft-ietf-isis-purge-tlv-03.txt
> 
> 
> > If IS purges its own LSP (because all of IP prefixes reported in
that
> LSP no longer reachable) then every IS (including the legacy systems)
> need purge it.
> 
> 

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".

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."

???

   Les

> I see no obvious way of addressing this other than instituting a flag
> day for the introduction of the Purge Originator Identification TLV.
> Does anyone see a better solution?
> 
> Regards,
> Tony
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Aug 2010 12:05:48 -0700

Hi Les,

> done in the spirit of being "strict in what you send but generous in

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.

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Aug 2010 15:56:13 -0700

Tony -

We are in agreement on all points.
But you asked " Does anyone see a better solution?".

My response was to say that one way of avoiding the problem - at least
most of the time - is to generate an empty non-purged LSP. This goes
against the recommended practice stated in ISO 10589 - but the rationale
for what is stated in 10589 is to minimize the size of the LSP database.
In fact having an empty LSP does not cause any operational problem. 

I think our collective experience indicates that being able to utilize
the mechanism in this draft ASAP is a good thing. Requiring a
network-wide upgrade as a prerequisite for enabling the functionality is
then undesirable. The choices left to us given the normative statements
in the existing authentication RFCs are then constrained.

My suggestion seems useable - are you saying via all the points below
that we should not even suggest this? Or do YOU have a better solution?
:-)

   Les

> From: Tony Li [mailto:[email-masked]]
> Sent: Thursday, August 12, 2010 12:06 PM
> To: Les Ginsberg (ginsberg)
> Cc: Minto Jeyananth; isis mailing list; [email-masked];
Adrian
> Farrel; Chris Hopps (chopps); ???; [email-masked]
> 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.
> 
> > the purge is initiated by owner of the LSP the problem may be
avoided
> by
>    in that LSP no longer exist, it is recommended that an IS purge
that
> LSP.
>    options), although purging is preferable. An IS should not allow
the
> LSP to age
> [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

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Aug 2010 16:03:55 -0700

Les,

I'm not rejecting your suggestion at all.  Simply hoping that someone younger and brighter will pull a rabbit out of their hat for us.  ;-)

Tony

---

From: Jie Dong <[email-masked]>
Date: Fri, 13 Aug 2010 17:01:07 +0800

Hi Tony, Les,

> 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.
> 
> change it) and then re-authenticate it.

Agree, authentication of the purge MUST be recalculated. Since there may be
other new TLVs defined in future which need to be carried in purge, it would
be better to specify which TLVs (which always exist in normal LSPs) MUST NOT
be carried in purge to ensure the re-authentication. Existence of other TLVs
should be accepted and can be used in authentication.

Best Regards,
Jie

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2010 08:05:17 -0700

Hi Jie,

> should be accepted and can be used in authentication.

True, that would be nice, but there's a practical problem: what would that list be?  Since an LSP can carry literally anything, what can you be sure would be there to be removed?

Regards,
Tony