Re: [secdir] ID Tracker State Update Notice: <draft-ietf-mpls-smp-requirements-08.txt>

Jeong Ryoo <ryoo@etri.re.kr> Sun, 28 September 2014 06:27 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1477C1A0361; Sat, 27 Sep 2014 23:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.686
X-Spam-Level:
X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVtpQ-dWRiLQ; Sat, 27 Sep 2014 23:27:02 -0700 (PDT)
Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E2D1A0369; Sat, 27 Sep 2014 23:27:01 -0700 (PDT)
Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 28 Sep 2014 15:27:01 +0900
Received: from SMTP2.etri.info ([169.254.2.204]) by SMTP4.etri.info ([169.254.3.126]) with mapi id 14.01.0355.002; Sun, 28 Sep 2014 15:26:54 +0900
From: Jeong Ryoo <ryoo@etri.re.kr>
To: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-smp-requirements@tools.ietf.org" <draft-ietf-mpls-smp-requirements@tools.ietf.org>, "kathleen.moriarty.ietf@gmail.com" <kathleen.moriarty.ietf@gmail.com>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "inacio@cert.org" <inacio@cert.org>
Thread-Topic: ID Tracker State Update Notice: <draft-ietf-mpls-smp-requirements-08.txt>
Thread-Index: AQHPsmNayeDI78BkGUuSzy4Zz94kZZwWWwq4
Date: Sun, 28 Sep 2014 06:26:53 +0000
Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170@SMTP2.etri.info>
References: <20140807171629.16181.95994.idtracker@ietfa.amsl.com>
In-Reply-To: <20140807171629.16181.95994.idtracker@ietfa.amsl.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-new-displayname: SmVvbmcgUnlvbw==
x-originating-ip: [129.254.28.41]
Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170SMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/L7lTKhecVcIVPjsJbKKHQzgQG6c
X-Mailman-Approved-At: Sun, 28 Sep 2014 07:47:20 -0700
Cc: "mpls@ietf.org" <mpls@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] ID Tracker State Update Notice: <draft-ietf-mpls-smp-requirements-08.txt>
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 28 Sep 2014 06:27:05 -0000

Hi, all.

Thanks for your comments and text proposals to this draft.

After close consultation with Adrian,
a new revision has been prepared and posted.

The changes are:
- Kathleen's proposed text is added in Security Section (Section 7)
- To clarify the term protection used in this document,
  a few sentences are added at the beginning of the second paragraph in Introduction Section
- Two nits from Chris are corrected.
- RFC 7258 is added in References section, and two unused references are removed.

There are two comments that have been considered, but did not result in text changes.
Their reasons for not changing are as follows:
1. Comment on the level of referencing in the security section
==>
This document refers RFCs 5921 and 5586, which are further referencing as in the
following diagram.
(Please view with courier font.)
Reducing one level does not seem to help a lot.
We would like to keep the current text to avoid repeating the texts of RFCs 5921 and 5586.
[This document]-+-> [RFC5921]-+-> [RFC3031]
                |             |
                |             +-> [RFC3985]-+-> [RFC3768]
                |             |             |
                |             |             +-> [RFC2401]
                |             |
                |             +-> [RFC5659]-+-> [RFC3985]-+-> [RFC3768]
                |             |             |             |
                |             |             |             +-> [RFC2401]
                |             |             |
                |             |             +-> [RFC5254]-+-> [RFC4447]
                |             |                           |
                |             |                           +-> [RFC3916]---> [RFC2401]
                |             |                           |
                |             |                           +-> [RFC4111]
                |             |                           |
                |             |                           +-> [RFC4364]-+-> [RFC4023]
                |             |                           |             |
                |             |                           |             +-> [RFC2385]
                |             |                           |
                |             |                           +-> [RFC3985]-+-> [RFC3768]
                |             |                           |             |
                |             |                           |             +-> [RFC2401]
                |             |                           |
                |             |                           +-> [RFC4107]
                |             +-> [RFC5920]
                |             |
                |             +-> [RFC6941]
                |
                +-> [RFC5586]-+-> [RFC4385]
                              |
                              +-> [RFC5085]-+-> [RFC4447]
                                            |
                                            +-> [RFC3931]---> [RFC1750]
                                            |
                                            +-> [RFC4023]---> [RFC2409]
                                            |
                                            +-> [RFC4379]---> [RFC1812]
                                            |
                                            +-> [RFC0792]
                                            |
                                            +-> [RFC4443]-+-> [RFC4302]
                                                          |
                                                          +-> [RFC4203]-+-> [RFC3630]-+-> [RFC2328]
                                                          |             |             |
                                                          |             |             +-> [RFC2154]
                                                          |             |
                                                          |             +-> [RFC2154]
                                                          |
                                                          +-> [RFC4301]
                                                          |
                                                          +-> [RFC2401]

2. Kathleen's second Comment, which overlaps with Stephen's
==>
The issue here concerns the quality of the back-up path compared to the primary path.
Thus, if the back-up path has lower security (for example, does not have lower
layer security) causing a failover is a way to be able to get at the data.
Or, if the back-up path goes through a point of pervasive monitoring, then
causing a failover is a way to get at the data.
Or, if the back-up-path is already congested, then causing a failover may be a
DoS on the protected traffic or on other traffic (e.g. through preemption).
None of this is radical or new. In fact, it is not new.

Best regards,

Jeong-dong


________________________________
보낸 사람 : "IETF Secretariat" <ietf-secretariat-reply@ietf.org>
보낸 날짜 : 2014-08-08 02:16:40 ( +09:00 )
받는 사람 : mpls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>, draft-ietf-mpls-smp-requirements@tools.ietf.org <draft-ietf-mpls-smp-requirements@tools.ietf.org>
참조 :
제목 : ID Tracker State Update Notice:

IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/