Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Jun 2002 16:57:10 -0400

On Wednesday, June 12, 2002, at 08:33 , Philip Christian wrote:
> 5. Security Considerations
>  
>    The proprietary TLV raises no new security issues for IS-IS. 

	Excuse me, but I don't think so.  I think that it raises new security
	issues because different vendors might use it in different ways.  In
	a multi-vendor environment there could be unintended consequences
	where A sends something with the new TLV that is syntactically
	valid with a different box B, but has unrelated semantics.

	Even if I'm confused, it is customary to outline *why* one thinks
	that no new security issues are raised, rather than making the
	assertion without supporting explanatory text.

>    Information placed in an IS-IS TLV cannot be considered secure,

	You've not defined "secure".  For "secure" == "authentic",
	then the IS-IS MD5 authentication can provide some security.
	If by "secure" you mean that "confidentiality" is provided,
	then please talk in terms of "confidentiality" rather than
	the vague term "secure".

> and
>    so if security is required then an implementation will need to
>    encrypt the information using a suitable method.

	This also seems wrong.  I'd suggest re-writing the whole section
	and in the re-write not using the word "secure" anyplace,
	instead using words like "integrity", "authentication", and/or
	"confidentiality" so that one's meaning is more crisp and clear.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Thu, 11 Jul 2002 11:22:13 -0400

At 04:57 PM 6/13/2002, RJ Atkinson wrote:

>        issues because different vendors might use it in different ways.

That would be using it incorrectly.  Only one authority can define
the syntax and semantics for a given OID.  If an implementation
misinterprets this information, that implementation is broken.

I agree with Philip that no NEW security issues arise from this RFC.
However, security issues may arise from a particular USE of this feature.
It is up to the designers of USES of this feature to address any
security issues that are raised by that application.

Regards,
Jeff

> In