Subject: Re: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

From: "Susan Hares" <[email-masked]>
Date: Wed, 18 Feb 2015 16:51:54 -0500

Alissa: 

Could you unpack your concerns a bit more on section 1 and this section?  Why is this not just a pragmatic comment on a reality of business that can happen?  This specification is documenting what exists in real networks with real costs. 

What causes you to hold your nose?  

Sue 

--------

The text: below: 

"This could result in a loss of revenue if the ISP is billing based on measured utilization
   of traffic sent to/from entities attached to its network."

Considering loss of revenue in and of itself to be a security issue is a slippery slope that we should probably not start to descend. I held my nose for the revenue-related text in Section 1, but here in Section 9 it seems particularly ill-advised.
========
Why is this not just a comment on a reality of business that can happen? What causes you to hold your nose? 

These  

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 3:37 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-idr-as-migration-03: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 9:
"This could result in a
   loss of revenue if the ISP is billing based on measured utilization
   of traffic sent to/from entities attached to its network."

Considering loss of revenue in and of itself to be a security issue is a slippery slope that we should probably not start to descend. I held my nose for the revenue-related text in Section 1, but here in Section 9 it seems particularly ill-advised.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 18 Feb 2015 16:51:54 -0500

Alissa: 

Sue 

--------

The text: below: 

These  

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 3:37 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

Section 9:
"This could result in a

---

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 18 Feb 2015 12:37:13 -0800

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.)

Section 9:
"This could result in a

Considering loss of revenue in and of itself to be a security issue is a
slippery slope that we should probably not start to descend. I held my
nose for the revenue-related text in Section 1, but here in Section 9 it
seems particularly ill-advised.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Feb 2015 14:50:14 -0800

> What causes you to hold your nose?  

Sure. If anything that causes any entity to lose (or gain) revenue can be considered a security issue, we would likely end up doing a lot of strange things in protocol design in the name of “security.” Furthermore, one entity’s loss can often be another’s gain, where neither entity would be considered an attacker in the sense of perpetrating an attack a la RFC 4949. So I think it makes a lot more sense to focus security considerations on technical threats and mitigations and not consider any particular party’s potential loss of revenue in and of itself as a security threat. 

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Feb 2015 14:50:14 -0800

Alissa

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 18 Feb 2015 19:28:03 -0500

Alissa:

OK - I can work with Wes to restate the text in a better way in section 9.
Alia had some comments about the technical nature to beef up that section.  

On, section 1  was it this set of sentences that caused you to be concerned?

In addition, it is common practice in the industry
   for ISPs to bill customers based on utilization.  ISPs bill customers
   based on the 95th percentile of the greater of the traffic sent or
   received, over the course of a 1-month period, on the customer's
   access circuit.  Given that the BGP Path Selection algorithm selects
   routes with the shortest AS_PATH attribute, it is critical that the
   ISP does not increase AS_PATH length during or after ASN migration
   toward downstream transit customers or settlement-free peers, who are
   likely sending or receiving traffic from those transit customers.
   This would not only result in sudden changes in traffic patterns in
   the network, but also substantially decrease utilization driven
   revenue at the ISP.

If so, can you unpack more details on what concerned you?

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Wednesday, February 18, 2015 5:50 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; IESG;
[email-masked]; [email-masked]
Subject: Re: [Idr] Alissa Cooper's No Objection on
draft-ietf-idr-as-migration-03: (with COMMENT)

On Feb 18, 2015, at 1:51 PM, Susan Hares <[email-masked]> wrote:

> Alissa: 
> 
> Could you unpack your concerns a bit more on section 1 and this section?
Why is this not just a pragmatic comment on a reality of business that can
happen?  This specification is documenting what exists in real networks with
real costs. 
> What causes you to hold your nose?  

Sure. If anything that causes any entity to lose (or gain) revenue can be
considered a security issue, we would likely end up doing a lot of strange
things in protocol design in the name of "security." Furthermore, one
entity's loss can often be another's gain, where neither entity would be
considered an attacker in the sense of perpetrating an attack a la RFC 4949.
So I think it makes a lot more sense to focus security considerations on
technical threats and mitigations and not consider any particular party's
potential loss of revenue in and of itself as a security threat. 

Alissa

> Considering loss of revenue in and of itself to be a security issue is a
slippery slope that we should probably not start to descend. I held my nose
for the revenue-related text in Section 1, but here in Section 9 it seems
particularly ill-advised.
> http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/
slippery slope that we should probably not start to descend. I held my nose
for the revenue-related text in Section 1, but here in Section 9 it seems
particularly ill-advised.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 18 Feb 2015 19:28:03 -0500

Alissa:

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Wednesday, February 18, 2015 5:50 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; IESG;

Alissa

---

From: "George, Wes" <[email-masked]>
Date: Thu, 19 Feb 2015 12:40:53 -0500

This document is written by two operators, documenting the operational
issue that makes this functionality important  which in turn drove them to
write the document. Therefore I do think that it's important to draw the
connection between As-Path lengthening and revenue loss, as this is the
business reality.

As to whether revenue loss is a security issue, I think this is a problem
of semantics. Nearly every security issue has at its core a risk of
revenue loss or data loss, but it's usually a result of a security
problem, the thing that you are trying to avoid by addressing the security
problem, rather than the problem itself. So there's certainly room to
reword to address this I think.

Thanks,

Wes

On 2/18/15, 7:28 PM, "Susan Hares" <[email-masked]> wrote:

>nose
>nose

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 19 Feb 2015 12:40:53 -0500

Thanks,

Wes

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Feb 2015 06:54:20 +0900

> issue that makes this functionality important which in turn drove them
> to write the document. Therefore I do think that it's important to
> draw the connection between As-Path lengthening and revenue loss, as
> this is the business reality.

i am an operator.  i do not support this statement.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Feb 2015 06:54:20 +0900

randy

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Feb 2015 22:35:46 +0000

On 19/02/2015 21:54, Randy Bush wrote:
> On 19/02/2015 17:40, George, Wes wrote:
1. >> This document is written by two operators
2. >> documenting the operational issue that makes this functionality important
3. >> which in turn drove them to write the document.
4. >> Therefore I do think that it's important to draw the connection
between As-Path lengthening and revenue loss
5. >> as this is the business reality.

> i am an operator.  i do not support this statement.

not meaning to pick nits, but which statement?

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Feb 2015 07:41:58 +0900

> i am an operator.  i do not support this statement.

after my first cuppa, allow me to expand.

when this doc first came out, i asked, with negligible success, it be
put on a radical diet.  so i thought what the heck, i have bigger fish
to fry.  same for it's mate over in sidr, which is the one about which i
care more.  but it seems the iesg has reached a similar conclusion.  so
let me try to suggest how.

we all agree the hack needs to be documented, you do not need to sell or
otherwise motivate it.  to accomplish x you need to do y.  fertig.

so get all the non technical stuff out.  and i mean all.  if you need to
save the immortal prose, publish it as a ripe series ops doc (and if you
say bcop i will puke).

try a gedanken experiment of seeing how little you can say to convey the
hack to the vendor and the op who has to configure it.  i bet you can
get it down to 3-4 pages excluding ietf boilerplate.  think of it like
code, the more of it there is the more room for bugs.

college years our roomies were at iit architecture, the mies school.
less is more.

randy

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 19 Feb 2015 17:54:29 -0800

> Alia had some comments about the technical nature to beef up that section.  

Thanks.

> If so, can you unpack more details on what concerned you?

I think Randy’s comment sort of summed up my feeling on this. Of course there are business realities, but the RFC series doesn’t exist to document them, to the benefit of Internet engineering (IMO).

In any event, I said I was able to hold my nose about this bit in Sec 1 and I meant it, so it’s up to your discretion as to whether you want to make changes here.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 19 Feb 2015 17:54:29 -0800

Thanks.

Alissa

---

From: "Neil J. McRae" <[email-masked]>
Date: Fri, 20 Feb 2015 07:49:28 +0000

> i am an operator.  i do not support this statement.

I agree with Randy I am also an operator and don't agree with the statement either.

I would add without this functionality it makes it very hard to integrate networks which could lead to security issue, increased costs or a loss in revenue. Having integrated about 20 networks and then returned the AS numbers it is also environmentally friendly. 

But frankly the points l've made above and the original objection don't belong here - the functionality is optional so if you think revenue is an issue don't do it. 

Regards
Neil.

---

From: "Neil J. McRae" <[email-masked]>
Date: Fri, 20 Feb 2015 07:49:28 +0000

Regards
Neil.