Re: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv - other comments

["Les Ginsberg (ginsberg)" <[e-mail]>]

Uma -

In regards to the new Section 5 on deployment considerations, I think your presentation is a bit misleading. It suggests that if you follow the steps outlined (enable send only, then enable verify) that you are guaranteed a hitless transition. But this is only the case if there is no replay attack occurring during the transition. I think you need to emphasize that for the appropriate scope (link for IIHs, SNPs - area/domain for LSPs) that the transition to "verify" needs to be made as close to atomically as possible so as to avoid inconsistencies which can occur if a replay attack occurs during the transition window.

In regards to the usefulness of the extension in LSPs I think your presentation is less than candid. You say in Section 2 that LSPs are vulnerable to inter-session replay attack - but, as we have previously discussed at length, the inter-session LSP replay attack scenarios are highly unlikely and the same base protocol mechanisms which protect LSPs against intra-session replays also allow the protocol to quickly recover from inter-session attacks. This differs markedly from the case for IIHs and SNPs where no replay protection is available at present.

The value add of Extended Sequence # in LSPs is about as close to nil as one can get. I would much prefer if the use of Extended Sequence #s in LSPs was removed from the draft (with explanation as to why). If you are unwilling to do that at least be fair in your presentation. You have a good use case argument for IIHs and SNPs - but the case for LSPs is quite weak and it would be good to be candid about that so vendors/customers can understand the value proposition .

   Les


From: Uma Chunduri [mailto:[e-mail]]
Sent: Tuesday, October 09, 2012 4:36 PM
To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (naiming)
Cc: Mike Shand; [e-mail]; [e-mail]
Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other comments

Les,

Replies in-line [Uma]:


Here are the remainder of my comments on the draft:

In regards to SNPs, the presence of replayed SNPs will cause unnecessary reflooding of LSPs but will not actually cause any change in the LSPDB of any router. The unnecessary flooding would be limited to the link on which the replayed SNPs appear. Because no actual LSPDB changes would occur as a result of replayed SNPs, this is the one usage which could be enabled in the presence of partial deployment.

In regards to IIHs, replayed IIHs could cause adjacency flapping which could be very disruptive. The danger lies when not all systems on a link support the extension - which on multi-access links can lead to multiple DISs being elected and violations of the assumption of transitivity. For this reason, enablement cannot be safely done in the presence of legacy systems.

[Uma]:  draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been updated (section 5) to cover the partial deployment cases. This addressees not only IIH but all PDUs. There is no flag day requirement here.

Given the discussion in the draft about enhancements to provide routing protocols with a group key management protocol in the future, it is prudent to look at the value add of extended sequence #s in the presence of a group key management protocol. The cost of having router vendors and their customers implement, deploy, and support extended sequence #s must be weighed against the benefits.

[Uma]: You talked about the cost above. When an operator deploys any  key management protocol in general, the advantages it brings in are far more bigger than the mitigation of  replay attacks.  But, the cost could be prohibitive if any key management protocol including group key management is deployed only  for the purpose of replay protection. Just for this reason a manual key mechanism to effectively eliminate the issue with replay attack is always useful. This is clearly discussed in Section 1 of the document. It's also worth mentioning here,  neither such a group keying RFC which can derive keys for a group IGPs look for  exist yet nor a smooth mechanism for integration yet defined.

As discussed in an earlier thread, IS-IS already has a reliable mechanism to recover from replayed LSPs.

[Uma]: We discussed in length on this and reliable recovery comes only after the replay is successful and the certain damage it brings in all over.

We take this opportunity acknowledge for providing early feedback on the solution for partial deployment issue.

--

Uma C.