Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-extended-sequence-no-tlv-00

From: Uma Chunduri <[email-masked]>
Date: Wed, 22 Jan 2014 22:05:02 +0000

Les,

Thanks for the review. Replies in-line [Uma]

--
Uma C.

"the network" should be replaced by "a given link"
And the text applies to both CSNP and PSNP since the absence of an LSP entry in a CSNP can trigger the receiver to flood the missing LSP on that link.

[Uma]: Sure, will take care.

Also, if for some reason the sender increments the ESSN BEFORE the PSN wraps, is the following sequence legal?
ESSN:50 PSN: 1 ESSN:51 PSN: 1
The current text suggests it is NOT legal ("PSN MUST be greater") but that seems clearly broken as PSN must reset in order to rollover.
I offer this suggestion as regards the acceptance rules - which I think are simpler yet enforce the intended requirement:
a)ESSN must be non-zero
b)The combined unsigned 96 bit value (where ESSN is the 64 MSBs) MUST be greater than the previously received value.

[Uma]: Make sense, shall update. Thx.

In Section 4 I think the rules regarding the ESSN/PSN values are PDU independent and should be moved/combined with the text in Section 3

[Uma]: This is the residue of removing LSP stuff from the draft. Will consolidate.

Section 4.2.1

I do not like the term "DISs CSNP ESN TLV". The point being made is that ESN # history needs to be kept on a per adjacency/pdu type/level basis. It is true that in the case of LAN's only the DIS will send CSNPs, but if there is a DIS change I presume that the new DIS is free to start using an ESN # totally independent of what was used by its predecessor DIS. 

[Uma]: Sure. I will reflect this in the next version.

Section 5

Although you say previously that use of the ESN TLV is optional, it is clear that in order to achieve the goals of the extension that once "verify mode" is enabled the TLV MUST be present in every IIH/SNP sent. Any single PDU sent without the ESN TLV becomes a potential replay candidate. Therefore, once you enter "verify" mode, is it OK to accept a PDU which does not have a ESN TLV? As written the draft would indicate yes - the TLV can be omitted at any time - but I don't think that achieves the goals. Prior to entering verify mode it is certainly OK to have presence of ESN TLV optional - but I think not after. Clarifying text is needed.

[Uma]: Agree. Will add the clarifying text in Section 5.1 rather.

ISO 10589 should be in the references - and it should replace the reference to RFC 1195 in the Introduction. (i.e., RFC 1195 reference is unnecessary as well as used incorrectly)

[Uma]: Sure-

There is still some discussion of the relevance of this technology to LSPs. This is understandable and even necessary to (at a minimum) clearly articulate why the draft excludes the use of the TLV in LSPs. However I would find the discussion more palatable if it was confined to a single section (currently there is text in multiple sections)

[Uma]: I see only it's confined to Section 2.1. Can you clarify here?

 and the discussion emphasized the point that the duration of the disruption possible with replay attacaks using LSPs (even "inter-session") is "short-lived" - meaning it is sub-second in most cases and in all cases not significantly longer. I think that is a fair characterization based on the lengthy discussion which we had previously. It would also help to explain to newcomers why LSPs were excluded.

[Uma]:  I will restrict this to say it's short lived (I don't think you are asking to say - it is sub-second in most cases and in all cases not significantly longer).

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 23 Jan 2014 05:27:39 +0000

Uma -

Thanx for your reply - I think we are in agreement on all points. In regards to your question about where the discussion of LSPs occurs in the draft there is:

Introduction Paragraph 3
Section 2.1 Paragraph 2

I would prefer that the text in the Introduction be removed and that Section 2 be revised such that it has a sub-section which briefly discusses the existing replay protection in LSPs and the reasons why it was decided NOT to apply this extension to LSPs. It might be a clearer presentation if you have a sub-section on each PDU type.

   Les

> -----Original Message-----
> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Wednesday, January 22, 2014 2:05 PM
> To: Les Ginsberg (ginsberg); Christian Hopps; [email-masked] list
> Cc: Hannes Gredler
> Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-extended-sequence-no-
> tlv-00
> 
> Les,
> 
> And the text applies to both CSNP and PSNP since the absence of an LSP entry
> in a CSNP can trigger the receiver to flood the missing LSP on that link.
> 
> The current text suggests it is NOT legal ("PSN MUST be greater") but that
> seems clearly broken as PSN must reset in order to rollover.
> I offer this suggestion as regards the acceptance rules - which I think are
> simpler yet enforce the intended requirement:
> a)ESSN must be non-zero
> b)The combined unsigned 96 bit value (where ESSN is the 64 MSBs) MUST be
> greater than the previously received value.
> 
> In Section 4 I think the rules regarding the ESSN/PSN values are PDU
> independent and should be moved/combined with the text in Section 3
> 
> I do not like the term "DISs CSNP ESN TLV". The point being made is that ESN
> # history needs to be kept on a per adjacency/pdu type/level basis. It is
> true that in the case of LAN's only the DIS will send CSNPs, but if there is
> a DIS change I presume that the new DIS is free to start using an ESN #
> totally independent of what was used by its predecessor DIS.
> 
> Although you say previously that use of the ESN TLV is optional, it is clear
> that in order to achieve the goals of the extension that once "verify mode"
> is enabled the TLV MUST be present in every IIH/SNP sent. Any single PDU sent
> without the ESN TLV becomes a potential replay candidate. Therefore, once you
> enter "verify" mode, is it OK to accept a PDU which does not have a ESN TLV?
> As written the draft would indicate yes - the TLV can be omitted at any time
> - but I don't think that achieves the goals. Prior to entering verify mode it
> is certainly OK to have presence of ESN TLV optional - but I think not after.
> Clarifying text is needed.
> 
> ISO 10589 should be in the references - and it should replace the reference
> to RFC 1195 in the Introduction. (i.e., RFC 1195 reference is unnecessary as
> well as used incorrectly)
> 
> [Uma]: Sure-
> 
> There is still some discussion of the relevance of this technology to LSPs.
> This is understandable and even necessary to (at a minimum) clearly
> articulate why the draft excludes the use of the TLV in LSPs. However I would
> find the discussion more palatable if it was confined to a single section
> (currently there is text in multiple sections)
> 
>  and the discussion emphasized the point that the duration of the disruption
> possible with replay attacaks using LSPs (even "inter-session") is "short-
> lived" - meaning it is sub-second in most cases and in all cases not
> significantly longer. I think that is a fair characterization based on the
> lengthy discussion which we had previously. It would also help to explain to
> newcomers why LSPs were excluded.
> 
> [Uma]:  I will restrict this to say it's short lived (I don't think you are
> asking to say - it is sub-second in most cases and in all cases not
> significantly longer).

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 25 Jan 2014 03:42:33 +0000

Les,

A new version is posted and please see if the points raised by you are addressed.
Coming to the last 2 points please see my response below -

>I would prefer that the text in the Introduction be removed 
[Uma]: As Section 2 has pointers and more clear explanation we see no harm to keep this text.. 

>and that Section 2 be revised such that it has a sub-section which briefly discusses the existing replay protection in LSPs and the reasons why it was decided NOT to apply this extension to LSPs. It might be a clearer presentation if you have a sub-section on each PDU type.

[Uma]:Yes, I did this and posted the new version of the draft.

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 Jan 2014 06:18:27 +0000

Uma -

I have attached an edited version of the document with my comments - please look for "LES:".
There are some substantive comments and some editorial comments.

One of the comments I had made on the previous version was: 

" In Section 4 I think the rules regarding the ESSN/PSN values are PDU independent and should be moved/combined with the text in Section 3"

You did not do that - some of my comments are suggestions to make that change.

Thanx.

   Les

> Sent: Friday, January 24, 2014 7:43 PM
> >and that Section 2 be revised such that it has a sub-section which briefly
> discusses the existing replay protection in LSPs and the reasons why it was
> decided NOT to apply this extension to LSPs. It might be a clearer
> presentation if you have a sub-section on each PDU type.
>