Re: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers

"Adrian Farrel" <> Sat, 05 January 2013 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5127D21F858A; Sat, 5 Jan 2013 07:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DG1EECR0mlx0; Sat, 5 Jan 2013 07:38:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C00A321F8584; Sat, 5 Jan 2013 07:38:02 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id r05Fc0H7010505; Sat, 5 Jan 2013 15:38:01 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r05Fbw0a010477; Sat, 5 Jan 2013 15:38:00 GMT
From: "Adrian Farrel" <>
To: "'Dan Harkins'" <>
References: <>
In-Reply-To: <>
Date: Sat, 5 Jan 2013 15:37:58 -0000
Message-ID: <00a001cdeb5a$a4efb7d0$eecf2770$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFj7XcJdDDL9XvJlrKu9AYvnToDKpkO2N5A
Content-Language: en-gb
Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Jan 2013 15:38:04 -0000

Hi Dan,

The authors may care to comment further, but I think there are two points...

The regulatory codes are centrally allocated so the "screw-ups" that you refer
to are within those domains. That reduces the scope of the problem and also
reduces its impact. But maybe the document would benefit from a note on the
"risks of misconfiguration". I am not sure that that would belong in the
Security Considerations section, but space could certainly be found in the

Yes, Corrigenda are stable ITU-T references. They are found on the same web page
that gives download pointers for the Recommendations they correct.


> -----Original Message-----
> From: [] On Behalf Of Dan
> Harkins
> Sent: 03 January 2013 19:05
> To:;; draft-ietf-mpls-tp-itu-t-
> Subject: secdir review of draft-ietf-mpls-tp-itu-t-identifiers
>   Hello, and happy new year,
>   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 draft creates a new globally unique identifier for the Transport
> Profile of MPLS. RFC 6370, which created identifiers for MPLS-TP,
> uses the operator's AS as a globally unique identifier but this draft
> proposes an alternative: use the ITU-T Carrier Codes. It then goes
> about changing the identifiers created by RFC 6370 by substituting
> the ITU-T Carrier Code for the AS.
>   The security considerations state that the draft merely extends an
> information model and does not propose any protocol changes and
> therefore it does not introduce any new security concerns. This seems
> acceptable except that this extension relies on the global uniqueness
> of the ITU-T Carrier Codes (as RFC 6370 relies on the AS to be
> globally unique). Apparently "national regulatory authorities"
> ensure that they are unique in their regulatory domain (which is an
> ISO 3166-1 identified code) so as long as they don't screw up
> anything all is well. I think it might be worth mentioning the
> assumption that the "national regulatory authorities" will not make a
> mistake and what happens if they do. RFC 6370 relied on IANA to
> not make a mistake; this draft relies on all 249 entities that have an
> official code in ISO 3166-1 to not make a mistake.
>   Also, there is a normative reference to a "Corrigendum" of an ITU-T
> recommendation on "OAM functions and mechanisms for Ethernet
> based networks". I have never encountered such a document. Is it
> a stable reference?
>   regards,
>   Dan.