From nobody Thu Sep 30 15:13:03 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0383A1582; Thu, 30 Sep 2021 15:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 v9J4o7dGKFb6; Thu, 30 Sep 2021 15:12:42 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C32B3A1583; Thu, 30 Sep 2021 15:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=euA1e7soz4bBh/Afj6m3TrSJRad+mbQKjUDLmeCByXM=; b=i1srVo9M9ZSGESLISGo5b/kMm7 +LGT72cL2v1DoX8EOQKpe/+0PUctEoJ7jwvO6l+QEZNJvahqdopOGoXzLYSLMT/Iys7p+jGozK+Yy Wlw1hvog+lRPiFMnmcz6lml5roBkMPLsdXB8uLFBsys/qUc4CJovRyWXxnio61APTW/9UaM8PbxF4 FXbPWKO6WgBPcDyZ9HbacKl0zsKWaxAldclGFkVFLpdIdmk+TslM8bWS9q9ggfgUl2KofD2/KbO0k 6uayAbuCgGcZ+GVt4uWBlFzJQiD4mpExiDr1GAQ+d4fXjqZzoC2DPzTlyVVYYYTjMUOmSfsL1iVXm uIC7v3wQ==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:57617 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mW4I7-000SiD-MN; Thu, 30 Sep 2021 18:12:41 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A0165EA5-E5E7-49CF-BAF7-E5FD8E44CCD4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: "touch@strayalpha.com" In-Reply-To: <20210930213640.GR98042@kduck.mit.edu> Date: Thu, 30 Sep 2021 15:12:33 -0700 Cc: Wes Eddy , The IESG , draft-ietf-tcpm-rfc793bis@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Michael Scharf Message-Id: <1AF4AF43-2662-4225-A415-DCA1306AC91B@strayalpha.com> References: <163236803976.28405.5643771942452620510@ietfa.amsl.com> <20210930213640.GR98042@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3654.120.0.1.13) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 22:12:47 -0000 --Apple-Mail=_A0165EA5-E5E7-49CF-BAF7-E5FD8E44CCD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ben, Notes interspersed below. Joe =E2=80=94 Joe Touch, temporal epistemologist www.strayalpha.com > On Sep 30, 2021, at 2:36 PM, Benjamin Kaduk wrote: >=20 > Hi Wes, Joe, >=20 > Sorry for the slow reply -- I've been a bit fogheaded this week and = wanted > to be sure that I was clearheaded when writing on this topic, as it = seems > particularly important to be communicating clearly. >=20 > On Thu, Sep 23, 2021 at 11:16:20AM -0400, Wesley Eddy wrote: >> On 9/22/2021 11:34 PM, Benjamin Kaduk via Datatracker wrote: >>> (1) We incorporate some long-standing enhancements that improve the >>> security and robustness of TCP (in particular, random ISN and = protection >>> against off-path in-window attacks come to mind), but only at SHOULD = or >>> MAY requirements level. >>>=20 >>> For example, we currently say: >>>=20 >>> A TCP implementation MUST use the above type of "clock" for = clock- >>> driven selection of initial sequence numbers (MUST-8), and SHOULD >>> generate its Initial Sequence Numbers with the expression: >>>=20 >>> ISN =3D M + F(localip, localport, remoteip, remoteport, = secretkey) >>>=20 >>> and: >>>=20 >>> + RFC 5961 [37] section 5 describes a potential blind data >>> injection attack, and mitigation that implementations = MAY >>> choose to include (MAY-12). TCP stacks that implement >>> RFC 5961 MUST add an input check that the ACK value is >>> [...] >>>=20 >>> What prevents us from making a MUST-level requirement for randomized >>> ISNs? Is it just the fact that it was only a SHOULD in RFC 6528 and = a >>> perception that promoting to a MUST would be incompatible with = retaining >>> Internet Standard status? >>=20 >> I don't think a MUST for the specific expression used to generate a=20= >> random ISN is necessary since there could be other expressions that=20= >> suffice, [...] >=20 > To be clear, my primary question here is "are randomized ISNs = MUST-level > required?". That can be separated from "is the specific quoted = expression > the MUST-level way to do it?" (though I see a number of factors that > suggest that the quoted expression is in fact the correct expression, = which > we can discuss later if needed). In particular, randomized ISNs serve = to > provide protection from off-path attacks, which is basically a = baseline > requirement for new IETF work, these days. Yes, but TCP is decidedly old work. We are always ultra-careful to move = its goalposts slowly... > I see Joe's message saying that "[t]his update does not attempt to = change > existing IETF consensus", but that also merits a bit of unpacking. = The > previous standards-track documents that have content rolled into this > document had consensus when published, of course, and in the absence = of > other data points we must assume that such consensus continues to = hold. > However, I see several other data points that have appeared since the > publication of the documents in question, and as I consider all those = data > points I see a very real possibility (note: not certainty) that the = current > text of this document does not actually reflect current IETF = consensus. If > we consider, for example, QUIC, a protocol in some ways highly = analogous to > TCP, the design considerations for QUIC could be said to include = "encrypt > everything you can, and randomize the things you can't encrypt=E2=80=9D.= Consensus on QUIC !=3D consensus on TCP, for the reason stated above. Remember that one axiom of TCP is =E2=80=9Cthink twice before changing = TCP, then don=E2=80=99t=E2=80=9D, as a rule (I noted this as far back as = IETF 60 in 2004 on this very issue). There are exceptions, of course, = but they=E2=80=99re typically a lot more contentious and conservatively = considered than for new protocols. > Even the > inclusion of a single unencrypted ("spin") bit in QUIC was done only = after > extensive and controversial discussion, as an optional feature that is > forbidden from being always on, to allow for a reasonable anonymity = set > that obscures which endpoints have specifically disabled it. >=20 > In light of the historical context and deployed reality, "encrypt > everything you can" for TCP means "encrypt nothing" (at least as part = of > the core protocol spec), but that does not prevent us from acting on > "randomize everything else". =20 It doesn=E2=80=99t prevent us from acting, but AFAICT *we have not yet = acted*. Although we encourage randomization, it is never a substitute = for true security and should not be done at the expense of = interoperability - which is especially important for TCP. > So, while I see Joe's note about not > attempting to re-adjudicate consensus on these points while producing = this > document, I'm not sure that we can avoid some level of = re-adjudication. Agreed, but we have not - at least on this point. If we do, we really = need to send this back to the WG for that - and if we allow = readjudication of this point, what else? > Even producing clear guidance on when it is safe/appropriate to ignore = the > recommendation (e.g., use predictable ISNs) might suffice to reconcile = the > apparent conflict, in the form of more specific guidance that = overrules the > otherwise-conflicting general advice. I might be able to help suggest = some > text of this nature if appropriate, but will need a bit more of = guidance > for search queries to find the relevant content in the archives than = "long > threads in the archives for the RFCs that were 'rolled in'". (IETF = LC? > WGLC? Earlier?) Part of what needs to be considered is what you=E2=80=99re asking from = legacy endpoints and why. Again, TCP is not QUIC. > I note additionally (responding to Joe's remark about needing RNGs on = all > TCP endpoints, including IoT and legacy devices), that randomizing the = ISN > does not require an ongoing source of new random numbers. On the = contrary, > in order to provide the required clock-derived behavior, we = specifically > need to *not* get fresh randomness for each TCP connection. I don=E2=80=99t know why you have this position; if the ISN of new = connections can be predicted based on old ones, then all new connections = after the first one after reboot can be attacked. > ...We only need > one secret key that serves to decorrelate the phase of that clock Clock? Again, you must be thinking of some other system. TCP does not = start with a strict requirement of a clock. It requires only timers. > for each > potential connection (4-tuple) and render the phase unpredictable to = off-path > observers. The necessary properties seem to be present even if this = secret > key is set once at device provisioning time and never changed = subsequently > (though of course best practices would include the ability to change = it > later). >=20 > I would very much like to hear your thoughts on whether randomized = ISNs as > a concept are MUST-level required, and (if not) in what circumstances > non-randomized ISNs are appropriate. Randomized ISNs are useful only when I know enough about a connection to = attack BUT I can=E2=80=99t see any traffic from that connection - and I = want to perform such an attack. These attacks are typically relevant for = high-value connections, e.g., BGP, where taking down a connection has = consequences. We haven=E2=80=99t seen evidence of people attacking end = system connections this way; the only benefit is to crash the = connection, which can be retried.=20 >> suffice, and there is no interoperability concern as this is totally=20= >> local to the host. >=20 > When you say "no interoperability concern" that seems to be arguing = that > because there is no required behavior for interoperability, then we = cannot > put a MUST-level requirement; i.e., that we only use MUST-level > requirements when required for interoperability. I reject that = argument; > we make MUST-level requirements "all the time" when required for, = e.g., > security, even if correct behavior cannot be validated by the peer and = is > thus not a strict requirement for interoperability. MUSTs that are local to endpoints IMO belong in BCPs, not protocol = standards. They don=E2=80=99t define anything that prevents other = systems from working. >>=20 >>> Likewise, what prevents using stronger normative language (e.g., = MUST) >>> for the RFC 5961 protections? >>=20 >> At the time 5961 was published there were both concerns with the IPR = as=20 >> well as alternative approaches to achieving the needed robustness, = and=20 >> the working group explicitly decided on the requirements language = after=20 >> a lot of discussion. >=20 > The IPR claim appears to be https://datatracker.ietf.org/ipr/421/ = which was > made in 2004, some 18 years ago. It doesn't list an application or = patent > number so as to definitively conclude that the IPR has expired, but = given > the typical US patent lifetime of 20 years from filing date, it may = not > even still be in force by the time this document is published as an = RFC. That may be true, but would need to be confirmed, not just inferred. > If there are potential alternate approaches, then it seems we should > consider having the primary normative guidance relate to = functionality, > with a specific mechanism given as a known way to satisfy that = guidance. > (This is analogous to the proposed "MUST randomize ISNs" above vs = "MUST use > this specific formula".) There are many others, e.g., IPsec, TCP-AO, as well as simply fixing the = application to not be so disrupted by an interrupted connection. For = BGP, that means not dropping routes simply because the TCP connection = fails (which, IMO, was never a good assumption - TCP connectivity should = never have been used to infer IP reachability). > But neither of those seem conclusive on the question of "stronger = normative > language than MAY" for protection against blind in-window attacks, = since > the "SHOULD" level is between "MAY" and "MUST", if "MUST" is for some > reason inappropriate. =20 SHOULD is still stronger than MAY. Right now, it=E2=80=99s probably = SHOULD where interrupting connections matters and =E2=80=9Cdon=E2=80=99t = waste your time=E2=80=9D most everywhere else. > In particular, it seems that the IETF consensus has > evolved since the publication of RFC 5961, Call me when that RFC is updated with stronger language. That didn=E2=80=99= t happen yet, so you have (IMO) no basis for this claim. > and so I feel a need to attempt > to resolve the apparent disparity between what was in 5961 (and thus = is > currently in this draft) and the subsequent evolution of what the IETF > seeks to provide in our protocols. >=20 > Joe points out that this behavior is not always relevant for all > implementations, which would support "not MUST" but still seems = consistent > with "SHOULD". =20 It would need to be a very carefully crafted SHOULD, e.g., SHOULD for = BGP, except where BGP has been fixed to not be susceptible to this = issue, which should have already happened, so maybe not so much SHOULD = as COULD=E2=80=A6. (i.e., it=E2=80=99s not like BGP stood still either). > Additionally, my sense is that it can be very valuable to > enumerate cases where these mechanisms are known to not be relevant, = to aid > implementors in deciding whether or not to implement this = functionality. We did this already in rfc4953, in Sec 3. I think that=E2=80=99s the end of my comments, or at least were you = continued discussion on them. --- --Apple-Mail=_A0165EA5-E5E7-49CF-BAF7-E5FD8E44CCD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Ben,

Notes = interspersed below.

Joe
=E2=80=94
Joe Touch, = temporal epistemologist
www.strayalpha.com

On Sep 30, 2021, at 2:36 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi Wes, Joe,

Sorry for the slow = reply -- I've been a bit fogheaded this week and wanted
to = be sure that I was clearheaded when writing on this topic, as it = seems
particularly important to be communicating = clearly.

On Thu, Sep 23, 2021 at 11:16:20AM = -0400, Wesley Eddy wrote:
On 9/22/2021 11:34 PM, Benjamin Kaduk via Datatracker = wrote:
(1) We = incorporate some long-standing enhancements that improve the
security and robustness of TCP (in particular, random ISN and = protection
against off-path in-window attacks come to = mind), but only at SHOULD or
MAY requirements level.

For example, we currently say:
   A TCP implementation MUST use the above = type of "clock" for clock-
   driven = selection of initial sequence numbers (MUST-8), and SHOULD
=    generate its Initial Sequence Numbers with the = expression:

   ISN =3D M + = F(localip, localport, remoteip, remoteport, secretkey)

and:

=          +  RFC 5961 = [37] section 5 describes a potential blind data
=             in= jection attack, and mitigation that implementations MAY
=             ch= oose to include (MAY-12).  TCP stacks that implement
=             RF= C 5961 MUST add an input check that the ACK value is
=             [.= ..]

What prevents us from making a = MUST-level requirement for randomized
ISNs?  Is it = just the fact that it was only a SHOULD in RFC 6528 and a
perception that promoting to a MUST would be incompatible = with retaining
Internet Standard status?

I don't think a MUST for the = specific expression used to generate a
random ISN is = necessary since there could be other expressions that
suffice, [...]

To = be clear, my primary question here is "are randomized ISNs MUST-level
required?".  That can be separated from "is the specific = quoted expression
the MUST-level way to do it?" (though I = see a number of factors that
suggest that the quoted = expression is in fact the correct expression, which
we can = discuss later if needed).  In particular, randomized ISNs serve = to
provide protection from off-path attacks, which is = basically a baseline
requirement for new IETF work, these = days.

Yes, but TCP is decidedly old work. We are always = ultra-careful to move its goalposts slowly...

I see Joe's message saying that "[t]his update does not = attempt to change
existing IETF consensus", but that also = merits a bit of unpacking.  The
previous = standards-track documents that have content rolled into this
document had consensus when published, of course, and in the = absence of
other data points we must assume that such = consensus continues to hold.
However, I see several other = data points that have appeared since the
publication of = the documents in question, and as I consider all those data
points I see a very real possibility (note: not certainty) = that the current
text of this document does not actually = reflect current IETF consensus.  If
we consider, for = example, QUIC, a protocol in some ways highly analogous to
TCP, the design considerations for QUIC could be said to = include "encrypt
everything you can, and randomize the = things you can't encrypt=E2=80=9D.

Consensus on QUIC !=3D consensus on TCP, for the = reason stated above.

Remember that = one axiom of TCP is =E2=80=9Cthink twice before changing TCP, then = don=E2=80=99t=E2=80=9D, as a rule (I noted this as far back as IETF 60 = in 2004 on this very issue). There are exceptions, of course, but = they=E2=80=99re typically a lot more contentious and conservatively = considered than for new protocols.

Even the
inclusion of a single unencrypted ("spin") bit in QUIC was = done only after
extensive and controversial discussion, as = an optional feature that is
forbidden from being always = on, to allow for a reasonable anonymity set
that obscures = which endpoints have specifically disabled it.

In light of the historical context and deployed reality, = "encrypt
everything you can" for TCP means "encrypt = nothing" (at least as part of
the core protocol spec), but = that does not prevent us from acting on
"randomize = everything else".  

It doesn=E2=80=99t prevent us from acting, but = AFAICT *we have not yet acted*. Although we encourage randomization, it = is never a substitute for true security and should not be done at the = expense of interoperability - which is especially important for = TCP.

So, while I see Joe's note about not
attempting to re-adjudicate consensus on these points while = producing this
document, I'm not sure that we can avoid = some level of re-adjudication.

Agreed,= but we have not - at least on this point. If we do, we really need to = send this back to the WG for that - and if we allow readjudication of = this point, what else?

Even producing clear guidance = on when it is safe/appropriate to ignore the
recommendation = (e.g., use predictable ISNs) might suffice to reconcile the
apparent conflict, in the form of more specific guidance that = overrules the
otherwise-conflicting general advice. =  I might be able to help suggest some
text of this = nature if appropriate, but will need a bit more of guidance
for search queries to find the relevant content in the = archives than "long
threads in the archives for the RFCs = that were 'rolled in'".  (IETF LC?
WGLC? =  Earlier?)

Part of what needs to be considered is what = you=E2=80=99re asking from legacy endpoints and why. Again, TCP is not = QUIC.

I note additionally (responding to Joe's = remark about needing RNGs on all
TCP endpoints, including = IoT and legacy devices), that randomizing the ISN
does not = require an ongoing source of new random numbers.  On the = contrary,
in order to provide the required clock-derived = behavior, we specifically
need to *not* get fresh = randomness for each TCP connection.

I don=E2=80=99t know why you have this position; = if the ISN of new connections can be predicted based on old ones, then = all new connections after the first one after reboot can be = attacked.

 ...We only need
one = secret key that serves to decorrelate the phase of that clock =

Clock? Again, = you must be thinking of some other system. TCP does not start with a = strict requirement of a clock. It requires only timers.

for each
potential connection (4-tuple) and = render the phase unpredictable to off-path
observers. =  The necessary properties seem to be present even if this secret
key is set once at device provisioning time and never changed = subsequently
(though of course best practices would = include the ability to change it
later).

I would very much like to hear your thoughts on whether = randomized ISNs as
a concept are MUST-level required, and = (if not) in what circumstances
non-randomized ISNs are = appropriate.

Randomized ISNs are useful only when I know enough = about a connection to attack BUT I can=E2=80=99t see any traffic from = that connection - and I want to perform such an attack. These attacks = are typically relevant for high-value connections, e.g., BGP, where = taking down a connection has consequences. We haven=E2=80=99t seen = evidence of people attacking end system connections this way; the only = benefit is to crash the connection, which can be retried. 

suffice, and there is no = interoperability concern as this is totally
local to the = host.

When you say "no = interoperability concern" that seems to be arguing that
because there is no required behavior for interoperability, = then we cannot
put a MUST-level requirement; i.e., that we = only use MUST-level
requirements when required for = interoperability.  I reject that argument;
we make = MUST-level requirements "all the time" when required for, e.g.,
security, even if correct behavior cannot be validated by the = peer and is
thus not a strict requirement for = interoperability.

MUSTs that are local to endpoints IMO belong in = BCPs, not protocol standards. They don=E2=80=99t define anything that = prevents other systems from working.


Likewise, what prevents using stronger normative language = (e.g., MUST)
for the RFC 5961 protections?

At the time 5961 was published = there were both concerns with the IPR as
well as = alternative approaches to achieving the needed robustness, and
the working group explicitly decided on the requirements = language after
a lot of discussion.

The IPR claim appears to be https://datatracker.ietf.org/ipr/421/ which was
made in 2004, some 18 years ago.  It doesn't list an = application or patent
number so as to definitively = conclude that the IPR has expired, but given
the typical = US patent lifetime of 20 years from filing date, it may not
even still be in force by the time this document is published = as an RFC.

That may be true, but would need to be confirmed, = not just inferred.

If there are potential = alternate approaches, then it seems we should
consider = having the primary normative guidance relate to functionality,
with a specific mechanism given as a known way to satisfy = that guidance.
(This is analogous to the proposed "MUST = randomize ISNs" above vs "MUST use
this specific = formula".)

There are many others, e.g., IPsec, TCP-AO, as = well as simply fixing the application to not be so disrupted by an = interrupted connection. For BGP, that means not dropping routes simply = because the TCP connection fails (which, IMO, was never a good = assumption - TCP connectivity should never have been used to infer IP = reachability).

But neither of those seem = conclusive on the question of "stronger normative
language = than MAY" for protection against blind in-window attacks, since
the "SHOULD" level is between "MAY" and "MUST", if "MUST" is = for some
reason inappropriate. =  

SHOULD is = still stronger than MAY. Right now, it=E2=80=99s probably SHOULD where = interrupting connections matters and =E2=80=9Cdon=E2=80=99t waste your = time=E2=80=9D most everywhere else.

In particular, = it seems that the IETF consensus has
evolved since the = publication of RFC 5961,

Call me when that RFC is updated with stronger = language. That didn=E2=80=99t happen yet, so you have (IMO) no basis for = this claim.

and so I feel a need to = attempt
to resolve the apparent disparity between what was = in 5961 (and thus is
currently in this draft) and the = subsequent evolution of what the IETF
seeks to provide in = our protocols.

Joe points out that this = behavior is not always relevant for all
implementations, = which would support "not MUST" but still seems consistent
with "SHOULD".  

It would need to be a very carefully crafted = SHOULD, e.g., SHOULD for BGP, except where BGP has been fixed to not be = susceptible to this issue, which should have already happened, so maybe = not so much SHOULD as COULD=E2=80=A6.

(i.e., it=E2=80=99s not like BGP stood still = either).

Additionally, my sense is that it can be very = valuable to
enumerate cases where these mechanisms are = known to not be relevant, to aid
implementors in deciding = whether or not to implement this functionality.

We = did this already in rfc4953, in Sec 3.

I think that=E2=80=99s the end of my comments, or = at least were you continued discussion on them.

---


= --Apple-Mail=_A0165EA5-E5E7-49CF-BAF7-E5FD8E44CCD4--