[sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 04 January 2017 18:30 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CCF126D74; Wed, 4 Jan 2017 10:30:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Mirja Kuehlewind" <ietf@kuehlewind.net>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jan 2017 10:30:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/jDuwMmArCU3xdXcj3SJha43fwIY>
Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org
Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?=
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 18:30:59 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


First, thanks for a well written document!

A few question on the design; not to propose changes but I would like to
learn the reason why the design is as it is:
1) Why do you need to send two different negotiation capabilities for
each direction instead of just using two flags in the same capability?
And similar why don't you just announce multiple address families in the
same capability (using variable length)? 
2) Why are the Secure_Path elements and Signature_Block blocks not
aligned but in two different lists (given there is and one to one
mapping)? Wouldn't it be easier to just update one length field (at a
fixed position) and attached the new information at the end? Or to ask
the question differently: why is the format as shown in figure 8 not used
in the message itself (->this is related to Suresh's question)?

Questions on operation:
1) section 5 says "a BGPsec speaker MAY temporarily defer validation of
incoming BGPsec update messages". 
Does this mean it has to remember its state before applying the update
message such that is can revert to this state if it later detects that
die update message was not valid? Or what action is supposed to happen if
the update message is detected as not valid later on
2) sec 4.2 says "Next, the BGPsec speaker generates one or two
Are you sure it's at max 2? I guess this depends on the expected update
cycles of the algorithm compared to the devices. Given update cycles for
devices can be very slow and updates for algorithm can be fast if any
security problems are detected, I wouldn't recommend to limit this to
3) In relation to the comment above, I'm not a big fan of the algo
migration strategy in section 6.1. I understand the problem that all
router on the path need to potentially support the algo. However, you do
have an negotiation phase. So why don't you the advertise the signing
algorithm in the negotiation capabilities? In this case the sender could
at least choose to only send the one(s) that is/are also supported by the
receiver or not use BGPsec at all if there is no match. However, I also
understand that it is probably to late to change anything now and if
there is wg consensus, I'm fine with that...
4) section 8.1 says "the recipient of a valid BGPsec update message is
assured that the update propagated via the sequence of ASes listed in the
Secure_Path portion of the BGPsec_Path attribute."
Is that true? It is assured that at least these ASes have been crossed
but there might have been others on the path that did not sign the
BGPsec_Path attribute, no?
5) Is it really necessary to create registries for "BGPsec Capability"
and "BGPsec_Path Flags"? Given this is a really small number of
bits/flags, I think new RFCs that update this RFC are enough to define a
new use for these so far unused bits.

Further, editorial proposals:
1) I would propose to add the Confed_Segment flag in figure 5 (and call
the remaining flag field 'reserved')
2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1