Subject: Re: [secdir] secdir review of draft-ietf-ccamp-rfc4420bis-03

From: "Ross Callon" <[email-masked]>
Date: Fri, 3 Oct 2008 23:20:04 -0400

The way that the original draft defines the length field in TLV's is
different from pretty much every other related protocol. As a result
many implementers implemented the length field the same way as every
other length field in every other TLV in related protocols, rather than
the way that the old draft specified it. This caused interoperability
problems and was quickly flagged as a bug.

The way that the new updated draft defines / uses the length field is
consistent with a very large number of other routing protocol
specifications. Implementations have been consistent with the updated
draft (and therefore inconsistent with the old RFC) for quite a while. 

Ross

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: 03 October 2008 18:01
To: [email-masked]; [email-masked];
[email-masked]; Arthi Ayyangar
Cc: [email-masked]; secdir; [email-masked]; Ross Callon;
[email-masked]
Subject: secdir review of draft-ietf-ccamp-rfc4420bis-03

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document is a very limited update to RFC4420. In particular, it
changes only one thing: the length field in the TLV defined by 4420 is
changed such that it now includes the Type and Length in the length
calculation, whereas before, it contained the length of only the Value
portion.

This introduces no new security concerns that I can think of. My only
question is, how do implementations distinguish between this encoding
and the old one? The doc says nothing about a protocol version number
change corresponding to the change in the bits on the wire. I assume the
draft wouldn't be in last call if this were a real concern, but still,
I'm curious about this.

--Scott

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 4 Oct 2008 08:17:28 +0100

Hi Scott,

An survey in CCAMP found that deployable implementations had "done the right 
thing" (i.e. coded according to the bis - presumably by accident) other 
implementations were pre-deployment. Hence the bis can safely obsolete the 
previous RFC.

Cheers,
Adrian
----- Original Message ----- 
From: "Scott G. Kelly" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "secdir" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, October 03, 2008 11:01 PM
Subject: secdir review of draft-ietf-ccamp-rfc4420bis-03

>I have reviewed this document as part of the security directorate's ongoing 
>effort to review all IETF documents being processed by the IESG.  These 
>comments were written primarily for the benefit of the security area 
>directors.  Document editors and WG chairs should treat these comments just 
>like any other last call comments.
>
> question is, how do implementations distinguish between this encoding and 
> the old one? The doc says nothing about a protocol version number change 
> corresponding to the change in the bits on the wire. I assume the draft 
> wouldn't be in last call if this were a real concern, but still, I'm 
> curious about this.
>
> --Scott
>
>
>