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

["George, Wes" <[e-mail]>]

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" <[e-mail]> wrote:

>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:[e-mail]] On Behalf Of Alissa Cooper
>Sent: Wednesday, February 18, 2015 5:50 PM
>To: Susan Hares
>Cc: [e-mail]; [e-mail]; IESG;
>[e-mail]; [e-mail]
>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 <[e-mail]> 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
>
>>
>> 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:[e-mail]]
>> Sent: Wednesday, February 18, 2015 3:37 PM
>> To: The IESG
>> Cc: [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>> 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.
>>
>>
>>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr
>


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.