Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5310 (2462)

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Aug 2010 14:03:54 +0530

I am not sure I understand why an IS, if it has not been configured to be in a "transition mode" would process ISIS LS PDUs without the CRYPTO_AUTH TLV? Is then the errata that even while an IS is in the said mode, it MUST NOT process the purges without the CRYPTO_AUTH TLV? If this is the case then how different is this from an attack where a hostile IS sends an empty IIH without the CRYPTO_AUTH TLV thus bringing down the adjacencies.

This is also mentioned in the Security Considerations section of RFC5310 which states the following:

"There is a transition mode suggested where routers can ignore the
 CRYPTO_AUTH information carried in the PDUs.  The operator must
 ensure that this mode is only used when migrating to the new
 CRYPTO_AUTH-based authentication scheme, as this leaves the router
 vulnerable to an attack."

Cheers, Manav

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]] 
> Sent: Friday, August 13, 2010 12.25 AM
> To: Bhatia, Manav (Manav); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC5310 (2462)
> 
> 
> The following errata report has been submitted for RFC5310,
> "IS-IS Generic Cryptographic Authentication".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5310&eid=2462
> 
> --------------------------------------
> Type: Technical
> Reported by: Tony Li <[email-masked]>
> 
> Section: 3.5
> 
> Original Text
> -------------
> An implementation MAY have a transition mode where it 
> includes CRYPTO_AUTH information in the PDUs but does not 
> verify this information.  This is provided as a transition 
> aid for networks in the process of migrating to the new 
> CRYPTO_AUTH-based authentication schemes.
> 
> Corrected Text
> --------------
> An implementation MAY have a transition mode where it 
> includes CRYPTO_AUTH information in the PDUs but does not 
> verify this information.  This is provided as a transition 
> aid for networks in the process of migrating to the new 
> CRYPTO_AUTH-based authentication schemes.  ISes implementing 
> CRYPTO_AUTH authentication MUST NOT accept unauthenticated 
> purges.   ISes MUST NOT accept purges that contain TLVs other 
> than the authentication TLV.  These restrictions are 
> necessary to prevent a hostile system from receiving an LSP, 
> setting the Remaining Lifetime field to zero, and flooding 
> it, thereby initiating a purge without knowing the 
> authentication password.
> 
> Notes
> -----
> The RFC ignores the case of purges.  With explicit 
> definition, purge packets would not include authentication, 
> which would open a trivial vector for attack.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5310 (draft-ietf-isis-hmac-sha-07)
> --------------------------------------
> Title               : IS-IS Generic Cryptographic Authentication
> Publication Date    : February 2009
> Author(s)           : M. Bhatia, V. Manral, T. Li, R. 
> Atkinson, R. White, M. Fanto
> Category            : PROPOSED STANDARD
> Source              : IS-IS for IP Internets
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: RFC Errata System <[email-masked]>
Date: Thu, 12 Aug 2010 11:55:17 -0700 (PDT)

Section: 3.5

Original Text
-------------
An implementation MAY have a transition mode where it includes
CRYPTO_AUTH information in the PDUs but does not verify this
information.  This is provided as a transition aid for networks in
the process of migrating to the new CRYPTO_AUTH-based authentication
schemes.

Corrected Text
--------------
An implementation MAY have a transition mode where it includes
CRYPTO_AUTH information in the PDUs but does not verify this
information.  This is provided as a transition aid for networks in
the process of migrating to the new CRYPTO_AUTH-based authentication
schemes.

ISes implementing CRYPTO_AUTH authentication MUST NOT accept
unauthenticated purges.   ISes MUST NOT accept purges that contain
TLVs other than the authentication TLV.  These restrictions are
necessary to prevent a hostile system from receiving an LSP, setting
the Remaining Lifetime field to zero, and flooding it, thereby
initiating a purge without knowing the authentication password.

Notes
-----
The RFC ignores the case of purges.  With explicit definition, purge packets would not include authentication, which would open a trivial vector for attack.

Instructions:
-------------

Author(s)           : M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2010 01:56:50 -0700

Sorry, there's confusion here caused by the tool and spacing.  I'm proposing an additional paragraph, that is not connected to the original text, except positionally.

The additional text is simply:

>> ISes implementing 

I hope the rationale behind this is obvious.

Regards,
Tony

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Aug 2010 14:54:28 +0530

Tony,

Am I missing something? Why would an IS supporting CRYPTO_AUTH authentication accept a PDU without the CRYPTO_AUTH tlv?

Cheers, Manav

> From: Tony Li [mailto:[email-masked]] 
> Sent: Friday, August 13, 2010 2.27 PM
> To: Bhatia, Manav (Manav)
> Cc: RFC Errata System; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC5310 (2462)
> 
> 
> Sorry, there's confusion here caused by the tool and spacing. 
>  I'm proposing an additional paragraph, that is not connected 
> to the original text, except positionally.
> 
> > I am not sure I understand why an IS, if it has not been 
> configured to be in a "transition mode" would process ISIS LS 
> PDUs without the CRYPTO_AUTH TLV? Is then the errata that 
> even while an IS is in the said mode, it MUST NOT process the 
> purges without the CRYPTO_AUTH TLV? If this is the case then 
> how different is this from an attack where a hostile IS sends 
> an empty IIH without the CRYPTO_AUTH TLV thus bringing down 
> the adjacencies.
> > 
> > This is also mentioned in the Security Considerations 
> section of RFC5310 which states the following:
> >

---

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

Manav,

We never wrote that down.

Tony

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Aug 2010 21:38:12 +0530

Tony, 

I would believe that if someone is using mechanisms defined in RFC 5310 then it means that they desire cryptographic authentication of their PDUs. Now, if that's the case why would someone accept PDUs without any authentication information? The only case I can think of is when someone is in a transition mode which we have already covered in the Security Considerations section.

I understand that while its good to be explicit I don't necessarily agree on this being an errata.

Cheers, Manav

> Sent: Friday, August 13, 2010 8.33 PM
> Cc: RFC Errata System; [email-masked]; [email-masked]; 
> > Am I missing something? Why would an IS supporting 
> CRYPTO_AUTH authentication accept a PDU without the CRYPTO_AUTH tlv?
> > 
> > Cheers, Manav
> >

---

From: Radia Perlman <[email-masked]>
Date: Fri, 13 Aug 2010 10:49:24 -0700

Although this is sort of covered in the security considerations
section through the passing remark  "There is a transition mode
suggested where routers can ignore the
   CRYPTO_AUTH information carried in the PDUs."

I think it is well worth explicitly explaining the transition cases
likely to occur, starting with a network with no cryptographic
authentication.

The various intermediate states would occur in this order:
a) nobody doing cryptographic authentication
b) some ISs sending authentication...either *nobody* checking, or
everyone being willing to accept without authentication (the
difference between not checking and accepting unauthenticated, is that
you'd reject PDUs with an incorrect authentication field)
c) everyone sending authentication...still everyone being willing to
accept without authentication
d) one by one, configuring the routers to start only accepting
authenticated PDUs
e) finally, everyone sending and verifying.

So therefore, it is sensible to have the network (temporarily) in
state b). And I think this explanation might make the RFC more
readable.

Radia

On Fri, Aug 13, 2010 at 9:08 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 13 Aug 2010 11:25:44 -0700

Tony -

In the context of the discussion regarding
draft-ietf-isis-purge-tlv-03.txt, what is the point of
clarifying/correcting RFC5310 in this way given that we now need to
update this behavior to allow TLVs other than the authentication TLV in
purged LSPs?

I would also point out that draft-ietf-isis-mi-03.txt also stipulates
that the instance TLV MUST be retained in purged LSPs (see the last
paragraph of Section 2.1) - so we now have two cases that require TLVs
other than the authentication TLV to be included in purge LSPs.

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tony Li
> Sent: Friday, August 13, 2010 1:57 AM
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; RFC Errata System;
> [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5310 (2462)
> 
> 
> Sorry, there's confusion here caused by the tool and spacing.  I'm
> proposing an additional paragraph, that is not connected to the
> original text, except positionally.
> 
> > I am not sure I understand why an IS, if it has not been configured
> to be in a "transition mode" would process ISIS LS PDUs without the
> CRYPTO_AUTH TLV? Is then the errata that even while an IS is in the
> said mode, it MUST NOT process the purges without the CRYPTO_AUTH TLV?
> If this is the case then how different is this from an attack where a
> hostile IS sends an empty IIH without the CRYPTO_AUTH TLV thus
bringing
> down the adjacencies.

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2010 15:23:28 -0700

Les,

> update this behavior to allow TLVs other than the authentication TLV in

Do you have a better way?  There needs to be some text in 5310 for how to handle purges.  We don't want to add text that is a forward reference to every explicit TLV that can appear in purges in the future.  The text that I'm proposing simply puts 5310 on the same footing as 5304, which we have to address anyways.

> other than the authentication TLV to be included in purge LSPs.

Excellent, thanks for pointing that out.  

This suggests that we need a more generic mechanism.  It seems to me that the correct approach here is to create or extend an IANA registry of TLVs that can be found in purges.  This could become another column in the "TLV Codepoint Registry" or another independent registry.

RFC's that are then discussing purges could reference this registry.

Thoughts?

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 13 Aug 2010 16:51:18 -0700

Tony -

> Sent: Friday, August 13, 2010 3:23 PM
> To: Les Ginsberg (ginsberg)
> Cc: Bhatia, Manav (Manav); Chris Hopps; [email-masked] list; Ran
> Atkinson; [email-masked]; RFC Errata System;
> [email-masked] Farrel; [email-masked] White
> Do you have a better way?  There needs to be some text in 5310 for how
> to handle purges.  We don't want to add text that is a forward
> reference to every explicit TLV that can appear in purges in the
> future.  The text that I'm proposing simply puts 5310 on the same
> footing as 5304, which we have to address anyways.

I am thinking of this from what I think is a practical point of view.
RFC5304 updates RFC3567 - which is several years old. I would have
expected that folks who implemented RFC5310 would have used the same
purge strategy that was specified in 5304/3567 - despite the fact that
5310 (quite unintentionally I assume) did not include the necessary
explicit language. If they did, then they are already doing what the
errata is intended to clarify.

If they have not followed the RFC5304 procedures in regards to purge,
then telling them they need to introduce RFC5304 behavior seems
pointless if we intend to "immediately" follow this up by telling them
that the RFC5304 behavior needs to be updated to allow for TLVs other
than the authentication TLV in purge LSPs.

??

> This suggests that we need a more generic mechanism.  It seems to me
> that the correct approach here is to create or extend an IANA registry
> of TLVs that can be found in purges.  This could become another column
> in the "TLV Codepoint Registry" or another independent registry.
> 

An additional column in the existing registry seems like an excellent
idea to me.

   Les

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2010 18:34:51 -0700

Hi Les,

> than the authentication TLV in purge LSPs.

Agreed, if we come up with better instructions, we can amend both, and I have no issues with amending the text that I proposed in the errata.  However, to be cautious, it seemed better to propose something rather than nothing.

> An additional column in the existing registry seems like an excellent

Works for me.  Dear Chairs, how do we do this?

Regards,
Tony

---

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

Hi Manav,

Well, we're writing a specification, not a magazine article.  If you don't write things down, you leave them open to interpretation and omission.  If an implementer is not very careful about how they implement purge processing, they will produce an insecure implementation.  If they make a mistake because the specification is incomplete or unclear, then that's our responsibility.

Regards,
Tony

---

From: David Ward <[email-masked]>
Date: Fri, 13 Aug 2010 18:37:59 -0700

Only need a trivial draft to update registries.

-DWard

---

From: Jie Dong <[email-masked]>
Date: Sat, 14 Aug 2010 11:28:32 +0800

Hi Tony, Les, 

> RFC's that are then discussing purges could reference this registry.

An IANA registry would be a good way, and there can be two alternatives: 

1. A list of TLVs can be carried in purge;
2. A list of TLVs MUST NOT be carried in purge, most of which will be existing TLVs

They could have the same effect. Which way would be better? This may depend on whether many of the future TLVs will be carried in purge. If so, the latter one may bring less changes to the registry, and so the authentication of purge. If not, the first one is definitely better.

Best Regards,
Jie

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2010 23:13:14 -0700

> Only need a trivial draft to update registries.

We can do trivial.  ;-)

http://www.ietf.org/internet-drafts/draft-li-reg-purge-00.txt

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 14 Aug 2010 09:41:36 -0700

Tony -

Thanx for addressing this so promptly.
Text looks good. I believe all the references should be "normative" -
not "informative".

As a matter of completeness do we need to say anything about subTLVs?
For example

"The purge status defined for a given TLV applies to all subTLVs defined
for that TLV."

??

Does this also mean that the errata for RFC 5010 will be withdrawn - or
at at least revised to reflect the new information in the registry?

   Les (the provoker)

> Sent: Friday, August 13, 2010 11:13 PM
> To: David Ward
> Cc: Les Ginsberg (ginsberg); Chris Hopps; [email-masked]; Ran
> Atkinson; [email-masked]; [email-masked];
> Bhatia, Manav (Manav); [email-masked]; RFC Errata System

---

From: Tony Li <[email-masked]>
Date: Sat, 14 Aug 2010 10:52:13 -0700

Les,

> Text looks good. I believe all the references should be "normative" -

Ok.

> "The purge status defined for a given TLV applies to all subTLVs defined

Logically, it's hard to insert a subTLV without its container, so strictly, this isn't necessary.  However, it certainly can't hurt.

> at at least revised to reflect the new information in the registry?

I'd be happy to revise it to refer to the registry.  We'll be able to do this later in the errata process and once the registry change is in place.

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 14 Aug 2010 11:01:30 -0700

> Logically, it's hard to insert a subTLV without its container, so
> strictly, this isn't necessary.  However, it certainly can't hurt.
> 

The "no" case is obvious - but for the "yes" case in theory one could
start quibbling about which subTLVs are allowed and which aren't - I
would rather put that issue to rest w explicit language.

   Les