Subject: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 2015)

From: Christopher Morrow <[email-masked]>
Date: Sat, 18 Jul 2015 19:05:26 -0400

Howdy Grow folk,
I think at the meeting in 48hrs time Jon Scudder plans to ask (again)
for WGLC for: draft-ietf-grow-bmp
(https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt)

Let's all have  read through ,decide if we're happy and get this
pushed along to the IESG for review/pulication. This is the abstract
of the document:

"This document defines a protocol, BMP, that can be used to monitor
   BGP sessions.  BMP is intended to provide a more convenient interface
   for obtaining route views for research purpose than the screen-
   scraping approach in common use today.  The design goals are to keep
   BMP simple, useful, easily implemented, and minimally service-
   affecting.  BMP is not suitable for use as a routing protocol."

Thanks!
-chris morrow
(co-chair 1 or 2)

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 19 Jul 2015 04:54:00 -0400

> On Jul 18, 2015, at 7:05 PM, Christopher Morrow <[email-masked]> wrote:
> 
> Howdy Grow folk,

I support publication of this document.  My employer also has an implementation of this version of the protocol and a majority of the documented statistics counters.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 19 Jul 2015 11:09:21 +0200

Support to proceed with publication.

Best,
R.

On Sun, Jul 19, 2015 at 1:05 AM, Christopher Morrow <
[email-masked]> wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: t.petch <[email-masked]>
Date: Mon, 20 Jul 2015 10:53:33 +0100

Starting with the easy part, IANA Considerations, I would like to see
more.

I think that for most if not all the registries, you should be setting
up a table, with columns for the RFC in which it is defined and a
status, e.g. Current, Historic, Deprecated or some such.  I note that
the individual message types are not versioned, that is if you want to
change the format of a Peer Down notification, you either have the
change the BMP version or else deprecate Peer Down and introduce Peer
Downer or some such.

I think it a mistake not to define that assignment policy for the types
that are defined in this I-D.  They may become obsolete or superseded in
which case you need to specify what is required to update them.  I
believe that all the all the assignment policies should start at zero.

I would like to see a Group name for these registries - if there isn't
one, then BMP Initiation Message TLVs could appear after Blocks
Extensible Exchange Protocol and Route Mirroring TLVs after Route
Distinguisher Type Field.

10.1 'defines five message types ' and then lists seven

10.2 'defines nine statistics types ' and then lists fourteen

10.5 'defines four types ' and then lists five

10.6 most registries start with zero; this one starts with one and zero
has no assignment policy

10.8 'two types for information ' or 'two types of information '?

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Sunday, July 19, 2015 12:05 AM

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 20 Jul 2015 16:17:18 +0200

Thanks for your comments, Tom.

On Jul 20, 2015, at 11:53 AM, t.petch <[email-masked]> wrote:
> status, e.g. Current, Historic, Deprecated or some such.  

I believe IANA sort of does this as part of their normal procedures -- most registries I look at have the headings value, name, reference, or similar. They do not have a separate column for current/historic/deprecated, rather, IANA appears to favor putting an annotation such as "(deprecated)" in the description as needed. So, I think there is nothing to do here.

> I note that

True. You would pick on the only one-byte field in the whole document, wouldn't you? Nonetheless there is plenty of space available so I think this is not a serious issue and should neither hold up progress nor justify the effort of changing multiple implementations. IMHO.

> believe that all the all the assignment policies should start at zero.

I think the notion that change procedures are different for pre-existing code points depending on the assignment policy covering the code point in question is novel, however I've updated all the registries as you request.

(A conceivable consequence of the idea that assignment policy affects change procedures might be that FCFS code points could be deprecated by a simple request too, something I think would be frowned upon.)

> Distinguisher Type Field.

I don't understand this point.

> 10.6 most registries start with zero; this one starts with one and zero

<blush>. Fixed. Thanks. Also, in the case of 10.6 I listed zero as reserved.

> 10.8 'two types for information ' or 'two types of information '?

And written that way in multiple other sections too. Did you deliberately object only to this one? It scans OK for me but if the WG wants me to change the wording I'm not going to fight about it.

Note, I likely will NOT be at GROW (sorry) but I'd be happy to talk after IDR if you'd like to conclude f2f.

I've just submitted -11 with these changes.

Regards,

--John

---

From: t.petch <[email-masked]>
Date: Tue, 21 Jul 2015 09:19:01 +0100

John

Picking up on the point you say you do not understand, if you look at
5226bis, especially s 2.1, it provides a welcome clarification to the
nomenclature, defining a group as e.g.

'Border Gateway Protocol (BGP) Parameters'
with, e.g.,

'BGP Message Types'
as a registry thereunder.

I am suggesting that you choose, and specify in the I-D, a group name
under which the registries you are creating appear (as opposed to
letting IANA create one that suits them).

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 20, 2015 3:17 PM
Subject: Re: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7
2015)

> status, e.g. Current, Historic, Deprecated or some such.

I believe IANA sort of does this as part of their normal procedures --
most registries I look at have the headings value, name, reference, or
similar. They do not have a separate column for
current/historic/deprecated, rather, IANA appears to favor putting an
annotation such as "(deprecated)" in the description as needed. So, I
think there is nothing to do here.

> change the BMP version or else deprecate Peer Down and introduce Peer

True. You would pick on the only one-byte field in the whole document,
wouldn't you? Nonetheless there is plenty of space available so I think
this is not a serious issue and should neither hold up progress nor
justify the effort of changing multiple implementations. IMHO.

> believe that all the all the assignment policies should start at zero.

I think the notion that change procedures are different for pre-existing
code points depending on the assignment policy covering the code point
in question is novel, however I've updated all the registries as you
request.

(A conceivable consequence of the idea that assignment policy affects
change procedures might be that FCFS code points could be deprecated by
a simple request too, something I think would be frowned upon.)

> 10.6 most registries start with zero; this one starts with one and
zero

<blush>. Fixed. Thanks. Also, in the case of 10.6 I listed zero as
reserved.

> 10.8 'two types for information ' or 'two types of information '?

And written that way in multiple other sections too. Did you
deliberately object only to this one? It scans OK for me but if the WG
wants me to change the wording I'm not going to fight about it.

Note, I likely will NOT be at GROW (sorry) but I'd be happy to talk
after IDR if you'd like to conclude f2f.

Regards,

--John=

---

From: t.petch <[email-masked]>
Date: Tue, 21 Jul 2015 09:26:32 +0100

Looking at the Security Considerations, I would like to see more.

An SNMP MIB module calls out which objects might be sensitive to a GET
(or SET) while this just has a blanket warning. The Internet only exists
because this kind of information is propagated to all and sundry so if
this introduces a threat, then I think more detail is needed, especially
as the I-D goes on to say 'MAY use some type of secure transport' which
is somewhat open!  If, for example, this is more sensitive because it is
exposing Adj-RIB-in pre the application of policy, then I think that
that needs saying; or whatever.

I think that the last paragaph makes a good point, identifying a threat,
but weakens it by calling for mutual authentication, which can be a pig
to
achieve.  If the threat is masquerade of a monitored router, then only
the router needs authentication which is much easier, and so more likely
to happen.

/IPSec/IPsec/

Tom Petch

---

From: "Russ White" <[email-masked]>
Date: Tue, 21 Jul 2015 05:26:23 -0400

> Support to proceed with publication.

Support.

:-)

Russ

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 Jul 2015 05:50:43 -0400

I also support publication of draft-ietf-grow-bmp.

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 21 Jul 2015 17:22:37 +0000

+1 Support publication

Sriram

---

From: Ebben Aries <[email-masked]>
Date: Tue, 21 Jul 2015 22:59:56 +0200

support publication

On 07/19/2015 01:05 AM, Christopher Morrow wrote:
> (https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=V4WJF%2BC6g%2BF0DyGqUhE5247H124ekpCcy1f4x%2F9XEtU%3D%0A&s=58e343dc1a055a739a3937f70a23276d43d854adb525f2d88733d2a4e4e97068)
> 
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/grow&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=V4WJF%2BC6g%2BF0DyGqUhE5247H124ekpCcy1f4x%2F9XEtU%3D%0A&s=78d83fb84b9e958c3d17ad5ca5020532f74adeec7ad27bf620931a086e84e3a4
>

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 22 Jul 2015 02:45:30 -0400

> 	I also support publication of draft-ietf-grow-bmp.

Support publication as well for for -11.

-Jon

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Jul 2015 04:15:50 -0400

Support publication 

Sue Hares

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 22 Jul 2015 10:30:37 +0200

> letting IANA create one that suits them).

Thanks for the 5226bis pointer. I've uploaded -12 with (only) the following change:

   IANA is requested to create registries for the following BMP
   parameters, to be organized in a new group "BGP Monitoring Protocol
   (BMP) Parameters":

--John

---

From: Mohan Nanduri <[email-masked]>
Date: Wed, 22 Jul 2015 08:54:38 -0400

Support the publication of this document.

Cheers,
-Mohan

---

From: John G.Scudder <[email-masked]>
Date: Fri, 24 Jul 2015 10:18:27 +0200

> On Jul 21, 2015, at 10:26 AM, t.petch <[email-masked]> wrote:
> 
> this introduces a threat, then I think more detail is needed,

I take your point. On the other hand, I'm not prepared to write a thorough exploration of any conceivable misuse of the information that's exposed, since the information is (at least!) "everything that's in BGP, now and in the future". I've expanded the text a little to try to address the question, but if you (or others in the WG) think a more thorough treatment is needed, please send text (or a reference to an existing document). 

> especially
> is somewhat open!  

I'm not quite sure how this relates to your previous point since the transport part is specific to authentication, data integrity and transport protection. Possibly you were expecting confidentiality from the transport as well, or possibly you are thinking of what we were when that text was written, namely that authentication prevents an imposter from directly receiving the information. I've tried to address that too.

> If, for example, this is more sensitive because it is

I added some text to indicate why I think mutual is desirable.

> /IPSec/IPsec/

Fixed.

Proposed section below. No new draft issued, since I anticipate we may iterate on this. Please take a look and ideally either suggest modifications or ack and I'll publish it as -13.

--John

11.  Security Considerations

   This document defines a mechanism to obtain a full dump or provide
   continuous monitoring of a BGP speaker's local BGP table, including
   received BGP messages.  This capability could allow an outside party
   to obtain information not otherwise obtainable.  For example,
   although it's hard to consider the content of BGP routes in the
   public Internet to be confidential, BGP is used in private contexts
   as well, for example for L3VPN [RFC4364].  As another example, a
   clever attacker might be able to infer the content of the monitored
   router's import policy by comparing the pre-policy routes exposed by
   BMP, to post-policy routes exported in BGP.

   Implementations of this protocol MUST require manual configuration of
   the monitored and monitoring devices.

   Users of this protocol MAY use some type of transport providing
   mutual authentication, data integrity and transport protection, such
   as IPsec [RFC4303] or TCP-AO [RFC5925].  If confidentiality is
   considered a concern, a transport providing that as well could be
   selected.

   Unless a transport that provides mutual authentication is used, an
   attacker could masquerade as the monitored router and trick a
   monitoring station into accepting false information, or could
   masquerade as a monitoring station and gain unauthorized access to
   BMP data.  Unless a transport that provides confidentiality is used,
   a passive attacker could gain access to BMP data in flight.  However,
   BGP is not commonly deployed over a transport providing
   confidentiality, so it's debatable whether it's crucial to provide
   confidentiality once the data is propagated into BMP.

---

From: t.petch <[email-masked]>
Date: Mon, 27 Jul 2015 10:13:44 +0100

John

Looks good.

My thinking on 'MAY', coloured by comments I have seen previously from
ADs, is that 'MAY' means much the same as 'MAY NOT' and so adds little
to a specification!  I would be inclined, although not too strongly, to
be more assertive, something like

'Where the security considerations outlined above are a concern, users
of this protocol SHOULD .....'

I think it right to mention IPsec and TCP-AO here.  I wonder at the
absence of SSH, which is probably the only security protocol I have used
to access a router.  I wonder too, if the advent of the work of SIDR
will lead to X.509 certificates being the norm for routers, which would
facilitate other forms of security but suspect that that is too far off
to consider now.

Tom Petch

----- Original Message -----
From: "John G.Scudder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, July 24, 2015 9:18 AM

> this introduces a threat, then I think more detail is needed,

I take your point. On the other hand, I'm not prepared to write a
thorough exploration of any conceivable misuse of the information that's
exposed, since the information is (at least!) "everything that's in BGP,
now and in the future". I've expanded the text a little to try to
address the question, but if you (or others in the WG) think a more
thorough treatment is needed, please send text (or a reference to an
existing document).

> as the I-D goes on to say 'MAY use some type of secure transport'
which

I'm not quite sure how this relates to your previous point since the
transport part is specific to authentication, data integrity and
transport protection. Possibly you were expecting confidentiality from
the transport as well, or possibly you are thinking of what we were when
that text was written, namely that authentication prevents an imposter
from directly receiving the information. I've tried to address that too.

Fixed.

Proposed section below. No new draft issued, since I anticipate we may
iterate on this. Please take a look and ideally either suggest
modifications or ack and I'll publish it as -13.

--John

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Jul 2015 10:14:14 -0400

> to access a router.  I wonder too, if the advent of the work of SIDR

we had some similar machinations in SIDR about AO/SSH/IPSEC/etc....
when you look at deployed router gear, OFTEN there is no AO support,
IPSEC is tied up in 'other licenses' (or not available in certain
places due to ITAR/etc issues) and ssh is often not the 'openssh
binary' you have on your desktop... Sometimes it's a kludged together
mess that exists ONLY to do client/server 'command line' work, and not
as a library (or not in the fully functional ssh binary you normally
use) for generically tunneling things :(

'how do I secure transport' is "solved" in the IETF, but very clearly
'not solved' in the real world :(

> facilitate other forms of security but suspect that that is too far off

it's not clear, to me, that the cert for SIDR work on a device is
particularly helpful for anything other than loose identity of the
device at the far side... Inside a single ASN that map could be
(according to the sidr ops docs) "this cert is for my ASN" or "this
cert is this particular routing device" (which is really 'bgp speaker'
I suppose even).

The mechanics of managing certs MIGHT make 'welp, we'll just use certs
for auth!' happen though, I grant you.

-chris

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 27 Jul 2015 16:29:55 +0200

> of this protocol SHOULD .....'

Actually, given the paragraph in question addresses "users of this protocol" it's probably inappropriate to use 2119 language anyway, mea culpa. I'm inclined to just change it to "should consider using".

We could revise the spec to require a particular secure transport to be supported by the implementation. Unless the WG feels strongly that we should do that, though, I'm disinclined, as it would hold up progress and has evidently not been considered crucial by adopters so far. As Chris mentioned, we have experience in SIDR that trying to mandate a single secure transport is problematic in practice. :-(

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 27 Jul 2015 16:33:59 +0200

P.S. here's what's in my buffer now. I'll issue this as the next version tomorrow unless there's further discussion to incorporate.

--John

   Where the security considerations outlined above are a concern, users
   of this protocol should consider using some type of transport that provides
   mutual authentication, data integrity and transport protection, such
   as IPsec [RFC4303] or TCP-AO [RFC5925].  If confidentiality is
   considered a concern, a transport providing that as well could be
   selected.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Jul 2015 10:36:06 -0400

> P.S. here's what's in my buffer now. I'll issue this as the next version tomorrow unless there's further discussion to incorporate.

if I get a vote, it's for the text sent... I think tom has to say if
he's ok with this as well though.

---

From: t.petch <[email-masked]>
Date: Mon, 27 Jul 2015 16:35:16 +0100

Looks ok to me

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 27, 2015 3:33 PM

P.S. here's what's in my buffer now. I'll issue this as the next version
tomorrow unless there's further discussion to incorporate.

--John

   of this protocol should consider using some type of transport that
provides

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jul 2015 12:29:04 -0400

A few small comments.

>    continuous monitoring of a BGP speaker's local BGP table, including

Delete "local" as I believe it implies Loc-Rib.  Perhaps make "BGP routes"
instead of "BGP table".

[...]

>    the monitored and monitoring devices.

I suggest SHOULD.  This MUST will eventually get us into "trouble" when
someone decides that this sort of thing should be auto-provisioned as part
of some networking infra, potentially using other protocol hints.

>    monitoring station into accepting false information, or could

I don't know that mutual authentication is the only property you're looking for.
I think this also includes "data integrity and protection against replay".
See, e.g., RFC 4949 "Authentication Header".

FWIW, I think this bit of text will raise the ire of the security
directorate folks no matter how carefully we try to get it right.  I'd
suggest simply flagging this now and proactively ask them what we should put
here.  

>    considered a concern, a transport providing that as well could be

I think the security directorate will be happy to see this.

-- Jeff

---

From: t.petch <[email-masked]>
Date: Tue, 28 Jul 2015 12:49:51 +0100

On a different tack to my previous ones,

s3.2
   The passive party is configured to listen on a particular TCP port

Is there any particular port or is this something chosen for manual
configuration by consenting parties?

Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 27, 2015 5:29 PM

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 29 Jul 2015 08:44:33 +0200

> configuration by consenting parties?

The latter.

--John