Subject: [Idr] AD Review of draft-ietf-idr-shutdown-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 21 Apr 2017 19:05:22 +0000

Dear authors:

This document partially answers the “why did the session go down?” question by adding the ability to send other information as part of a Cease NOTIFICATION.  I say “partially” because it does so for only 2 of the existing subcodes.  Except for the draft’s name, there’s no justification or explanation of why all the current (or even future!) subcodes are not granted the ability to (optionally) send extra information.  Why?  I know that this point was brought up on the list [1], and the resolution seems to have simply been “that’s out of scope”.  Personally (taking my AD hat off!), I think it’s a shame – but I guess it’s also an opportunity to write a 1-line update to this document.  BTW, I don’t want to necessarily resurrect this point, I’m ok being in the rough…  [Putting my AD hat back on…]  It would be very nice if there was some text (a paragraph or two) explaining why just 2 subcodes, or maybe why not the others – I’m sure (or maybe I hope) that others will have similar questions.

Besides that rant, I do have some other comments (please see below) aimed mostly at clarifying.  I would like to (at least) see the comments about the Security Considerations addressed before starting the IETF Last Call.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/YJPgIdtZg7DrY4PliefkrPm6Kas/?qid=fb7d4b6fce9500d97f5b7ab25a062d53

C1. s/This document specifies…/This document updates [RFC4486] by specifying…

C2. s/Cease NOTIFICATION message [RFC4486]/Cease NOTIFICATION message [RFC4271] – or simply take the reference off.

C3. Section 2. (Shutdown Communication)

OLD>
   … then the BGP speaker MAY send to the neighbor a
   NOTIFICATION message with the Error Code "Cease" and Error Subcode
   "Administrative Shutdown" or "Administrative Reset" followed by a
   length field and an UTF-8 encoded string.

NEW>
…and it sends a NOTIFIATION message with the Error Code "Cease" and Error Subcode "Administrative Shutdown" or "Administrative Reset" [RFC4486], it MAY include an UTF-8 encoded string.

Objective: move the MAY to indicate that the extra string is optional, and not the whole thing.  I know that a BGP speaker may end up not sending the Cease because rfc4486 has a SHOULD in it…but I also wanted to avoid confusion between that SHOULD and this MAY.

C4. Please put a Figure number to go with the encoding.

C5. Section 4. (Error Handling): “Any erroneous or malformed Shutdown Communication received SHOULD be logged for the attention of the operator and then MAY be discarded.”

C5.1. What does “erroneous or malformed” mean?  I guess this is beyond a bad length, but maybe it refers to invalid UTF-8 sequences, or maybe something different.   ??

C5.2. Does the fact the content is erroneous mean that the NOTIFICATION should be ignored?  I would assume not…but the “MAY be discarded” part may raise questions.  Do you only discard the “Shutdown Communication” part?  Or the whole NOTIFICATION?  Where you storing NOTIFICATIONs to start with?  I guess an implementation can keep the string around for historical purposes…but that seems an implementation detail and nothing like that is specified in the document.

C5.3. Section 2 already talks about reporting the contents -- I’m assuming the logging requirement here is the same (do whatever you want, but syslog SHOULD be used), right?  If so, then how is the handling of the “erroneous or malformed” information different than that of the one that isn’t?

C6. Section 5. (IANA Considerations) Why do you want the registry to refer to this document?  There’s nothing in this document that modifies or affects the registry, the policies or the assignments…   I think that the Updates tag is enough to show the relationship.

C7. Section 6.  (Security Considerations)

C7.1. REQUIRING is not an rfc2119 keyword.  Please work REQUIRED in there instead.

C7.2. I agree on the points about integrity and confidentiality.  However, neither rfc4486, rfc4271 nor rfc4272 are as specific as you’re being here.  I don’t think this is the document where we want to have the discussion about explicitly upgrading to TCP-AO, even if it’s just mentioned as an example.  Suggestion:  leave the text about the potential concern, take both examples out, and point at the security considerations in rfc4271/rfc4272.

NEW>
   Users of this mechanism should be aware that unless a transport that
   provides integrity is used for the BGP
   session in question, a Shutdown Communication message could be
   forged.  Unless a transport that provides confidentiality
   is used, a Shutdown Communication message could be
   snooped by an attacker.  These issues are common to any BGP message
   but may be of greater interest in the context of this proposal since
   the information carried in the message is generally expected to be
   used for human-to-human communication.  Refer to the related considerations
   in [RFC4271] and [RFC4272].

C7.3. In the Shepherd’s write-up [2], Sue wrote: “The Security-ADs will look at the ability to send data which indicates specific details regarding an operator or the operator's topology.”  Given that the operator can put anything in the string, it would be nice if you addressed this concern up front (and not wait for the SEC ADs).  Even if the information is being sent to a “trusted” peer, I think Sue raises an interesting point as “confidential” information may be inadvertently sent out.  One way to address this concern may be with guidance to operators and to reaffirm the fact that while the information is sent only one hop away (to your peer), it can be used as the receiver’s discretion.

[2] https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/shepherdwriteup/

---

From: Job Snijders <[email-masked]>
Date: Sat, 22 Apr 2017 12:10:13 +0200

Dear Alvaro,

On Fri, Apr 21, 2017 at 07:05:22PM +0000, Alvaro Retana (aretana) wrote:
> This document partially answers the “why did the session go down?”
> question by adding the ability to send other information as part of a
> Cease NOTIFICATION.  I say “partially” because it does so for only 2
> of the existing subcodes.  Except for the draft’s name, there’s no
> justification or explanation of why all the current (or even future!)
> subcodes are not granted the ability to (optionally) send extra
> information.  Why?  I know that this point was brought up on the list
> [1], and the resolution seems to have simply been “that’s out of
> scope”.  Personally (taking my AD hat off!), I think it’s a shame –
> but I guess it’s also an opportunity to write a 1-line update to this
> document.  BTW, I don’t want to necessarily resurrect this point, I’m
> ok being in the rough…  [Putting my AD hat back on…]  It would be very
> nice if there was some text (a paragraph or two) explaining why just 2
> subcodes, or maybe why not the others – I’m sure (or maybe I hope)
> that others will have similar questions.

Following the documents history it is easy to see that originally we
proposed a new Cease subcode (which would mimic 'shutdown'), but were
encouraged to recycle an existing codepoint since there was an
opportunity for permissionless extension, and subsequently the utility
'shutdown' and 'reset' was defined as belonging to the same group.

The choice to 'just' decorate subcode 2 and 4 was driven out of
operational experience with the various shutdown events. 2 and 4 are
human initiated (or humans program a system to do it on their behalf).
The other sub cease codes are either driven out of existing automation
no immediate need to enrich them was identified ("maximum prefix",
"Connection Rejected")), or are poorly understood ("Other Configuration
Change") or rarely used ("Out of Resources").

We also analysed how the concept would fit in currently established CLI
paradigms, and identified that in most operating systems it would be
trivial to enrich the 'shutdown/down/disable' or 'clear/reset' commands
or configuration directives, but less so for the other types of events.

So in short: we looked at what is commonly used, and enriched those.
This leaves room for others to decorate the the other or future
subcodes, if they identified a need to be addressed.

> Besides that rant, I do have some other comments (please see below)
> aimed mostly at clarifying.  I would like to (at least) see the
> comments about the Security Considerations addressed before starting
> the IETF Last Call.

> C1. s/This document specifies…/This document updates [RFC4486] by specifying…

done.

> C2. s/Cease NOTIFICATION message [RFC4486]/Cease NOTIFICATION message [RFC4271] – or simply take the reference off.

ok, opted for RFC4271 

> …and it sends a NOTIFIATION message with the Error Code "Cease" and
> Error Subcode "Administrative Shutdown" or "Administrative Reset"
> [RFC4486], it MAY include an UTF-8 encoded string.
> 
> Objective: move the MAY to indicate that the extra string is optional,
> and not the whole thing.  I know that a BGP speaker may end up not
> sending the Cease because rfc4486 has a SHOULD in it…but I also wanted
> to avoid confusion between that SHOULD and this MAY.

thank you, accepted.

> C4. Please put a Figure number to go with the encoding.

done

> C5. Section 4. (Error Handling): “Any erroneous or malformed Shutdown
> Communication received SHOULD be logged for the attention of the
> operator and then MAY be discarded.”
> 
> C5.1. What does “erroneous or malformed” mean?  I guess this is beyond
> a bad length, but maybe it refers to invalid UTF-8 sequences, or maybe
> something different.   ??

Yes, section 2 "A receiving BGP speaker MUST NOT interpret invalid UTF-8
sequences." So, what a BGP speaker could do is send a hexdumped version
of the received data to syslog after something like "printf("%02x",
*p++);", rather then present that data through usual ways (as UTF-8).

> C5.2. Does the fact the content is erroneous mean that the
> NOTIFICATION should be ignored?  I would assume not…but the “MAY be
> discarded” part may raise questions.  Do you only discard the
> “Shutdown Communication” part?  Or the whole NOTIFICATION?  Where you
> storing NOTIFICATIONs to start with?  I guess an implementation can
> keep the string around for historical purposes…but that seems an
> implementation detail and nothing like that is specified in the
> document.

Following the Cease NOTIFICATION the TCP session will be torn down, so
even if you ignore the NOTIFICATION, the BGP speaker will have to deal
with a torn down session anyway. But, I'll remove "and then MAY be
discarded". It is indeed up to implementers to decide whether they want
to keep it around. OpenBGPD keeps it around in a 'show bgp
neighbor'-style command, exabgp & pmacct don't.

> C5.3. Section 2 already talks about reporting the contents -- I’m
> assuming the logging requirement here is the same (do whatever you
> want, but syslog SHOULD be used), right?  If so, then how is the
> handling of the “erroneous or malformed” information different than
> that of the one that isn’t?

I envision that in the invalid case one simply logs "received malformed
shutdown communication", with perhaps a hexdump of what was received,
and in the normal situation a bgp speaker decodes the string as UTF-8,
syslogs the result, and perhaps stores it for historic purposes. Do you
have a suggestion how to clarify?

perhaps, NEW:

    """
    If an erroneous or malformed Shutdown Communication is received, a
    message indicating this event SHOULD be logged for the attention of
    the operator.  An erroneous or malformed Shutdown Communication
    itself MAY be logged in a hexdump format.
    """

> C6. Section 5. (IANA Considerations) Why do you want the registry to
> refer to this document?  There’s nothing in this document that
> modifies or affects the registry, the policies or the assignments… I
> think that the Updates tag is enough to show the relationship.

Because 4486 is updated, and 4486 instantiated those entries. I believe
there is benefit in providing this additional way to show the relation.
A developer or debugger might go straight to the registry looking for
just the value mapping, and then be happy to learn that subcode 2 & 4
could be followed by trailing data which is encoded in a specific way.

> C7.1. REQUIRING is not an rfc2119 keyword.  Please work REQUIRED in

OK, I got that from RFC 5424, so we might need an errata there.

OLD:
    This document guards against the technical issues outlined in UTR36
    by REQUIRING "shortest form" encoding.
NEW:
    UTF-8 "Shortest Form" encoding is REQUIRED to guard against the
    technical issues outlined in UTR36.

> C7.2. I agree on the points about integrity and confidentiality.
> However, neither rfc4486, rfc4271 nor rfc4272 are as specific as
> you’re being here.  I don’t think this is the document where we want
> to have the discussion about explicitly upgrading to TCP-AO, even if
> it’s just mentioned as an example.  Suggestion:  leave the text about
> the potential concern, take both examples out, and point at the
> security considerations in rfc4271/rfc4272.
> 
> NEW>

OK, accepted.

> C7.3. In the Shepherd’s write-up [2], Sue wrote: “The Security-ADs
> will look at the ability to send data which indicates specific details
> regarding an operator or the operator's topology.”  Given that the
> operator can put anything in the string, it would be nice if you
> addressed this concern up front (and not wait for the SEC ADs).  Even
> if the information is being sent to a “trusted” peer, I think Sue
> raises an interesting point as “confidential” information may be
> inadvertently sent out.  One way to address this concern may be with
> guidance to operators and to reaffirm the fact that while the
> information is sent only one hop away (to your peer), it can be used
> as the receiver’s discretion.
> 

Interesting point. Do you think XMPP, SMTP, NNTP, and SYSLOG, include
similar clauses? I personally may want to wait for a security AD to
actually make and argue the point rather then 'preempt' the angle with
text which borders on legalese.

Following your feedback, we'll post an update shortly.

Kind regards,

Job

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 24 Apr 2017 21:59:47 +0000

On 4/22/17, 6:10 AM, "Job Snijders" <[email-masked]> wrote:

Job:

Hi!

…
> *p++);", rather then present that data through usual ways (as UTF-8).

Ok, so “erroneous or malformed” just refers to an “invalid UTF-8 sequence”?  If so, then just say that and don’t leave it up to interpretation.

…
>     itself MAY be logged in a hexdump format.

That text seems fine to me.  

> could be followed by trailing data which is encoded in a specific way.

That still doesn’t seem needed to me, but I’m happy to let IANA raise a flag if it is an issue for them.

> OK, I got that from RFC 5424, so we might need an errata there.

It looks like we do.

…
> similar clauses? 

I don’t know, did you look? ;-)

All those protocols were standardized before the IAB/IESG acquired a new taste for privacy.  Take a look at rfc6973 and at this short review [3].

[3] https://ietf.org/edu/tutorials/89-Privacy-Tschofenig.pdf 

> I personally may want to wait for a security AD to

No need to be too clever when writing this up; all you need is a recognition that secondary use of the data can occur, some recommendations about how to mitigate (by not including too much), and maybe a pointer to rfc6973.

Thanks!

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Apr 2017 17:03:13 -0400

[Largely addressed to Alvaro using Job's points.]

> Change") or rarely used ("Out of Resources").

There's also the simple matter that a number of the behaviors for some of
these subcodes have implications for conformance testing suites.  Those
suites know what happens when you hit those controls in the CLI and
preserving the subcodes leverages existing conformance work.

Arguably, there's a chance in behavior by adding stuff to the DATA field,
but there's supporting precedent in 4271 to ignore things you don't
understand there.

In short, this was a good fit for the use case.

-- Jeff