Subject: [Isis-wg] Proprietary / Private TLV numbers Security Considerati ons

From: Jeff Parker <[email-masked]>
Date: Thu, 11 Jul 2002 12:55:26 -0400

Philip -
	Here is an attempt to reword things to address 
Ran's observations.  I'm out the door, but you have 
the active support of the group to bang this into shape.  

Ran -
	I've used the term 'mischief' as a place holder.
Can you suggest a better word to cover the threats that 
Virii and Trojan horses represent?

- jeff parker 

5. Security Considerations 

   The contents of IS-IS PDUs are not protected by encryption,
   so the contents of TLVs in LSPs are visible throughout the
   routing area or domain, while the contents of Hello Packets,
   CSNPs, and PSNPs are visible to observers on the link they 
   are sent to.  The addition of MD5 authentication, as described
   in [draft mumble] can increase the integrity of TLVs, while
   encryption could increase their confidentiality.  

   The general extensibility of the TLV mechanism has always allowed
   the addition of new information, and the possibility of conflicting
   interpretations of such information by different implementations.  
   This proposal does not introduce a new quality of information: it 
   simply allows an increase in the quantity of such additions.  As 
   such, it represents no new potential for mischief.  

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 11 Jul 2002 23:54:15 -0400

>    are sent to.  The addition of MD5 authentication, as described

Proposed edit:
	The addition of cryptographic authentication, as described in
	[draft mumble] provides integrity and authentication of TLVs.
	Because of the manner in which IS-IS operates, any router
	possessing the correct IS-IS keying material could inject
	incorrect information into the entire IS-IS domain.

>    in [draft mumble] can increase the integrity of TLVs,

> while encryption could increase their confidentiality.

What sort of encryption did we have in mind here ?

I don't know of a proposal in the IS-IS WG for adding encryption
(and I'm far from persuaded that an IGP needs confidentiality, btw).
As this runs on the link-layer, the only off-the-shelf mechanism
I can think of off-hand is IEEE 802.10 (Ethernet Security).
Unfortunately there are negligible numbers of 802.10 implementations,
AFAIK.

Maybe we should just say something like:

	The IS-IS specification does not provide confidentiality.  As this
      extension is part of an interior routing protocol, whose purpose
	is to disseminate information about the routing topology, it is
	not clear that confidentiality is normally required.  If an operator
	believes that confidentiality is required in their network,
	a link-layer mechanism (e.g. IEEE 802.10) will be required.

>    such, it represents no new potential for mischief.

Hmm.  I don't quite agree with the sense of the paragraph.  There is
a new potential for mischief, but it doesn't seem resolvable in this
document.  Seems fair to note that in the document.

I'd suggest something more like:

	As with any extension, there is the possibility that different
	implementations would accidentally interpret a given extension
      in different ways.   As this amounts to an implementation error,
	there is no obvious protocol specification fix for this risk.
      Implementers are encouraged to make the processing of this
      extension particularly robust against unexpected formats and
	against unexpected data values.

	Because this extension is generic, rather than specific, it is
	not possible to describe all potential security risks in all
	potential proprietary extensions deployed using this mechanism.
	Hence, vendors are encouraged to document their extensions and
	the security properties of their extensions so that operators
	can make informed deployment and operations decisions about
	such proprietary extensions.

Would this fly with folks here ?

Ran
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 12 Jul 2002 08:52:20 -0700

>     such proprietary extensions. 

hmm, not saying this is incorrect but Ran may be trying to close
the barn after the horse bolted. If I have the possiblity to inject 
information
into the ISIS domain, I will just fake up topology in well-known format
packets rather than going through the pains of faking other people's
proprietary stuff ...

    thanks

    -- tony

---

From: Mike Truskowski <[email-masked]>
Date: Fri, 12 Jul 2002 09:25:48 -0700 (PDT)

I agree.  Why do we have this issue when there are other ways
to screw up a network.

mike

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 13 Jul 2002 03:44:39 -0400

> packets rather than going through the pains of faking other people's

Tony P,

I'm not trying to close the door so much as note that the door is open
and try to get the door manufacturer to mention the width and
height of the door... :-)

Ran

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 13 Jul 2002 09:31:36 -0700

> height of the door... :-)

Ran,

point taken, my analogy was a tad strained. I agree with you and I deem
to notice a (weak though) consensus to write things down. Thinking further,
the proprietary TLV draft may not be the best guinea pig do achieve that.
Maybe a separate 'Security considerations' draft is necessary that all
coming out/future ISIS RFCs are obliged to point to (unless they open
more holes)

    thanks

    -- tony