Subject: RE: [Isis-wg] Proprietary / Private TLV numbers Security Consider ati ons

From: "Philip Christian" <[email-masked]>
Date: Thu, 11 Jul 2002 18:24:58 +0100

Maybe if we take Jeff's text and just change the last sentence then we get:-

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-ietf-isis-hmac-03.txt 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 security issues for IS-IS*.

Philip  

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 5:55 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]'; [email-masked]'
Subject: [Isis-wg] Proprietary / Private TLV numbers Security
Considerati ons

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.

---

From: "Philip Christian" <[email-masked]>
Date: Fri, 12 Jul 2002 10:41:54 +0100

The information in the TLV is proprietary.  After the first three bytes (the
OUI) a vendor can put whatever they like there.

This implies that if the vendor wants to encrypt the bytes before they nail
an OUI onto the front of it, then they are free to do so.

As the extension is proprietary, then a vendor is free to use whatever
encryption they choose (including none).  Additionally I would imagine that
it would be quite hard to understand what the bytes from another vendor mean
anyway.  After the OUI the format and use of the rest of the TLV will be
unknown to anyone other than the vendor whose box made them.  It would be
like trying to read a page of test of an unknown language; if you don't know
the language that you have no dictionary.

Therefore I think that stating where the TLV goes (generally limited to an
operator's network), and stating that no encryption is provided by IS-IS is
a good enough statement.  People know what they have on their hands then,
which is the point of this section I would have thought.

If a vendor considers the information in the TLV sensitive, then they now
have the information to decide whether to encrypt or not.

As the TLV is proprietary, there is no way that we can know what people are
going to put in there.  Therefore we can't prescribe what encryption /
authentication is needed.

A formula that goes

1. Here is what you get as standard.
2. Here is what you can do if "1" isn't good enough.

should be sufficient for the intended use, in my opinion.

That said, I am no security expert, and I don't really have any problems
with your text if people prefer it.

Regards, Philip

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Friday, July 12, 2002 4:54 AM
To: Jeff Parker
Cc: [email-masked]'
Subject: Re: [Isis-wg] Proprietary / Private TLV numbers Security
Considerati ons

>    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]

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