Subject: [Isis-wg] (no subject)

From: "appallar" <[email-masked]>
Date: Thu, 15 Apr 2004 00:01:02 +0530

Hello,

 When an LSP ages out, should the checksum recalculated and modified, or left unmodified?
as per ISO 10589, check sum should not be modified. In section 7.3.16.4, "Note 32" says a check of the checksum succeeds even though the data portion is not present.

How about the authentication part? do an implementation keep authentication while aging LSPs?
and if authentication information is present, how does checksum succeeds?

as per RFC 3719, if the checksum errors found, the LSPs are dropped, so do all implementations check Remaining life time before check sum??

Thanks in advance,
SuryanarayanaIndiatimes Email now powered by APIC Advantage. Help! 
HelpClick on the image to chat with me

---

From: Tony Li <[email-masked]>
Date: Wed, 14 Apr 2004 16:01:41 -0700

We tried to explain this in the authentication RFC.  If there is no body
to the LSP, then you can't really have authentication.  And without 
authentication, this gives folks a trivial way to attack you.  
Therefore, you MUST retain some portion of the body and, when 
authentication is enforced, you must ignore 0 age LSPs that have no 
body.

The system generating a 0 age LSP can either then retain the entire 
body of the LSP or remove the body and recalculate the authentication.  
Either is acceptable.

Tony

On Apr 14, 2004, at 11:31 AM, appallar wrote:

>  Hello,  When an LSP ages out, should the checksum recalculated and 
> modified, or left unmodified? as per ISO 10589, check sum should not 
> be modified. In section 7.3.16.4, "Note 32" says a check of the 
> checksum succeeds even though the data portion is not present. How 
> about the authentication part? do an implementation keep 
> authentication while aging LSPs? and if authentication information is 
> present, how does checksum succeeds? as per RFC 3719, if the checksum 
> errors found, the LSPs are dropped, so do all implementations check 
> Remaining life time before check sum??  Thanks in advance, 
> Suryanarayana
> Indiatimes Email now powered by APIC Advantage. Help!
> Help

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Sun, 18 Apr 2004 02:11:42 -0700

At 04:01 PM 4/14/2004 -0700, Tony Li wrote:

>authentication is enforced, you must ignore 0 age LSPs that have no body.
>
>The system generating a 0 age LSP can either then retain the entire body 
>of the LSP or remove the body and recalculate the authentication.
>Either is acceptable.
>
>Tony
>

Although I hesitate to critique the author of the authentication RFC, the 
answer Tony has provided is actually partly at odds with both RFC 3567 and 
ISO 10589. RFC 3567 says:

"ISes(routers) that implement HMAC-MD5 authentication and initiate LSP
    purges MUST remove the body of the LSP and add the authentication
    TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
    unauthenticated purges.  ISes MUST NOT accept purges that contain
    TLVs other than the authentication TLV."

ISO 10589  7.3.16.4 says:

"When the Remaining Lifetime on an LSP in memory becomes zero, the IS shall
a)      set all SRMflags for that LSP, and
b)      retain only the LSP header."

So both specs indicate that it is required that the body of an LSP be 
removed prior to purging and that the receiving system MUST (at least in 
the case of RFC 3567) reject purged LSPs that have anything in the body 
other than the authentication TLV.

I agree with Tony that retaining the body in a purged LSP in principle does 
no harm (other than wasting LSP DB space) but because there are 
implementations out there which adhere to the requirements in the two 
specs, it is quite possible that such an LSP will be rejected by some 
systems when received.

As for the original question, an old defect in 10589:1992 existed wherein 
Section 7.3.14.2e directed systems to purge received LSPs which had an 
incorrect checksum. This proved disruptive in practice and was corrected to 
indicate that the receiving system should ignore such an LSP (see 
corresponding section in 10589:2002). However, this correction did not 
extend to 7.3.14.2i (as it should have). The text in RFC 3719 is meant to 
clarify that all LSPs received with a checksum error, even if the invalid 
checksum is 0, should be ignored rather than purged.

As to why Note 32 (Note 36 in 10589:2002) is necessary, this is a result of:

7.3.11 which says: "The checksum shall never be modified by any other system"

AND

The quote above from 7.3.16.4 which requires the system issuing a purge to 
NOT retain the LSP body.

Taken literally, these two statements would require a system which is 
purging an LSP generated by another system to remove the body, thereby 
making the checksum invalid, and prohibit that system from recalculating 
the checksum. So unless the checksum check were suspended in the case of 
purged LSPs, it would fail on receive.

    Les

>> modified, or left unmodified? as per ISO 10589, check sum should not be 
>> modified. In section 7.3.16.4, "Note 32" says a check of the checksum 
>> succeeds even though the data portion is not present. How about the 
>> authentication part? do an implementation keep authentication while 
>> aging LSPs? and if authentication information is present, how does 
>> checksum succeeds? as per RFC 3719, if the checksum errors found, the 
>> LSPs are dropped, so do all implementations check Remaining life time 
>> before check sum??  Thanks in advance, Suryanarayana