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

Huub helvoort <huub.van.helvoort@huawei.com> Mon, 07 January 2013 13:58 UTC

Return-Path: <huub.van.helvoort@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE921F86F7; Mon, 7 Jan 2013 05:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeTssiQ1NogC; Mon, 7 Jan 2013 05:58:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A77A621F86D4; Mon, 7 Jan 2013 05:58:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANG82104; Mon, 07 Jan 2013 13:58:42 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 Jan 2013 13:57:35 +0000
Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.01.0323.003; Mon, 7 Jan 2013 13:58:38 +0000
From: Huub helvoort <huub.van.helvoort@huawei.com>
To: "afarrel@juniper.net" <afarrel@juniper.net>, 'Dan Harkins' <dharkins@lounge.org>
Thread-Topic: secdir review of draft-ietf-mpls-tp-itu-t-identifiers
Thread-Index: AQHN6eU/uyehI2LrqU+v9clAyT9105g64XsAgAME2gs=
Date: Mon, 07 Jan 2013 13:58:37 +0000
Message-ID: <73E555AA235F3846B8051DB38C8776272E57FA00@lhreml509-mbx>
References: <6398d2a9aea631a9b8b7224b48cdaa00.squirrel@www.trepanning.net>, <00a001cdeb5a$a4efb7d0$eecf2770$@juniper.net>
In-Reply-To: <00a001cdeb5a$a4efb7d0$eecf2770$@juniper.net>
Accept-Language: en-GB, en-US, zh-CN
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.202.112.156]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 07 Jan 2013 06:02:43 -0800
Cc: "draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org" <draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 13:58:45 -0000

Hello Dan,

Thank you for the review.

Adrian already addressed your concerns, I would like to provide soem extra information.
See my comments in-line [Huub]

________________________________________
From: Adrian Farrel [afarrel@juniper.net]
Sent: 05 January 2013 16:37
To: 'Dan Harkins'
Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org
Subject: RE: secdir review of draft-ietf-mpls-tp-itu-t-identifiers

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.

[Huub] correct, each country is responsible for allocating and using unique operator
identification codes: the ICC. This is explained on this page:
http://www.itu.int/oth/T0201
To make them globally unique the CC has to be added.

 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
document.

[Huub] would a reference to http://www.itu.int/oth/T0201  be enough?

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

[Huub] see http://www.itu.int/ITU-T/recommendations/rec.aspx?id=11136&lang=en

Best regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...


> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Dan
> Harkins
> Sent: 03 January 2013 19:05
> To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mpls-tp-itu-t-
> identifiers.all@tools.ietf.org
> 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.