Subject: [sidr] pCNT & prepending

From: Danny McPherson <[email-masked]>
Date: Thu, 28 Jul 2011 11:02:11 -0400

Doug et al, 
I like the general objective of pCNT and this seems a good idea to me.  My only comment at the microphone was that if we add this for compression, then validation should require that pCNT MUST be equal to the number of _contiguous ASx appearances in the path (i.e., no more, no less, and only contiguous).

I do wonder if pCNT=0 for transparent route servers introduces the opportunity for some sort of downgrade attack of sorts..

-danny

---

From: XIANG Yang <[email-masked]>
Date: Thu, 28 Jul 2011 23:11:17 +0800

+1 support.
It's import to defend "AS removal" attack.
_____________________________________________________
Yang Xiang, PhD student, Tsinghua Univ., about.me/xiangyang

2011/7/28 Danny McPherson <[email-masked]>

>
> Doug et al,
> I like the general objective of pCNT and this seems a good idea to me.  My
> only comment at the microphone was that if we add this for compression, then
> validation should require that pCNT MUST be equal to the number of
> _contiguous ASx appearances in the path (i.e., no more, no less, and only
> contiguous).
>
> I do wonder if pCNT=0 for transparent route servers introduces the
> opportunity for some sort of downgrade attack of sorts..
>
> -danny
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 28 Jul 2011 11:11:58 -0400

Danny,

Yes, that is certainly the idea if we agree to protect prepending (as opposed to just avoiding multiple Sigs in the the presence of prepending).

If we protect prepending, the pCNT must be carried in the protocol, covered by the Sig and verified ... i.e., what you suggest below .. in validation.

Note, that if you don't want to protect prepending ... only avoid repeating sigs ..., then you don't have to carry pCNT in the protocol.  Just update the Sig verification algorithm treat sequences of repeated AS's as one.

If we like the "translucent" approach to support RS, then we need to carry pCNT in BGSSEC.   You are right we do need enhanced receive/process rules such as:

1. Only accept pCNT=0 from peers that are configured to be route servers.

2. Don't accept paths with multiple pCNT=0 entries in a row.

Anyway, if we like this approach, we can talk the details of the receiving rules / process rules to protect potential abuse.

dougm

Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Danny McPherson [[email-masked]]
Sent: Thursday, July 28, 2011 11:02 AM
To: sidr wg list
Subject: [sidr] pCNT & prepending

Doug et al,

-danny

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 28 Jul 2011 11:12:16 -0400

Did your comment mean complete "AS removal" ... or defending against adding/removing pre-pends.

dougm

Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of XIANG Yang [[email-masked]]
Sent: Thursday, July 28, 2011 11:11 AM
Cc: sidr wg list
Subject: Re: [sidr] pCNT & prepending

+1 support.
It's import to defend "AS removal" attack.
_____________________________________________________
Yang Xiang, PhD student, Tsinghua Univ., about.me/xiangyang<http://about.me/xiangyang>

2011/7/28 Danny McPherson <[email-masked]<mailto:[email-masked]>>

Doug et al,

-danny
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: XIANG Yang <[email-masked]>
Date: Thu, 28 Jul 2011 23:18:22 +0800

Sorry for the ambiguity. I mean defending against attacks such as "removing
an AS from the path".
I.e.
suppose the path is <AS1 AS2 AS2 AS3>,
then we need pCNT to avoid AS3 to announce a shorter path <AS1 AS2 AS3>, by
remove one of AS2.

R.

2011/7/28 Montgomery, Douglas <[email-masked]>

> From: [email-masked] [[email-masked]] On Behalf Of XIANG
> Yang [[email-masked]]

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 28 Jul 2011 11:24:17 -0400

OK  so that is a +1 for protecting prepending, not just optimizing Sigs in
the presence of prepending.

From:  XIANG Yang <[email-masked]>
Date:  Thu, 28 Jul 2011 23:18:22 +0800
To:  Doug Montgomery <[email-masked]>
Cc:  sidr wg list <[email-masked]>
Subject:  Re: [sidr] pCNT & prepending

> Sorry for the ambiguity. I mean defending against attacks such as "removing an
> AS from the path".
> I.e.
> <http://about.me/xiangyang>
> 
> 
> 
>> <http://about.me/xiangyang> <http://about.me/xiangyang>
>> 
>> 
>> 
> _______________________________________________ sidr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Jul 2011 11:27:27 -0400

> It's import to defend "AS removal" attack.

you do not support tranparent route servers?

randy

---

From: Highwayman <[email-masked]>
Date: Thu, 28 Jul 2011 11:31:46 -0400

It's not clear to me how the system is protected from some unscrupulous transit provider setting their AS's to zero width, in order to attract more traffic.  Unless there is a side channel for ASN which may validly announce themselves in this way ?

I agree that transparency is the minimum requirement. I do not, yet, discount the emotional demand for Route Server users to not be seen to be RS users.  For many years we peered at LINX and, frankly, would not have dreamt of either using the RS, or be seen to be using it -- we were big boys -- notwithstanding, we peered openly... go figure :-)

Chris
-- 
Chris Hall.                  +44 7970 277 383 (iPhone)

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 28 Jul 2011 11:53:32 -0400

I think we would all benefit from your offer to survey the RS community to
see if solutions that did not effect PATH_LENGTH but do make the RS AS#
visible somewhere in the protocol (we can quibble about the syntax of
carrying that in AS_PATH vs PATH_SIGs later).

If one requires dropping routes with pCNT=0 from peers that are not
administratively configured to be route servers, then allowing a
unscrupulous transit provider to propogate that, now requires collusion
between two AS's.   There are other issues that come up if we consider
those scenarios.

One could think of having RS's somehow announce/declare themselves (e.g.,
an RPKI object/flag) ... But I will point out that if I am unscrupulous I
will just announce myself and proceed.

Anyway, again ... Let's get the requirement right before we talk about the
encoding / mechanisms - you offer to survey if "translucent" supports the
use case / business model of the RS community is an important step towards
getting the requirement right.

Dougm

On 7/28/11 11:31 AM, "Highwayman" <[email-masked]> wrote:

>It's not clear to me how the system is protected from some unscrupulous
>transit provider setting their AS's to zero width, in order to attract
>more traffic.  Unless there is a side channel for ASN which may validly
>announce themselves in this way ?
>
>I agree that transparency is the minimum requirement. I do not, yet,
>discount the emotional demand for Route Server users to not be seen to be
>RS users.  For many years we peered at LINX and, frankly, would not have
>dreamt of either using the RS, or be seen to be using it -- we were big
>boys -- notwithstanding, we peered openly... go figure :-)
>
>Chris
>-- 
>> Yes, that is certainly the idea if we agree to protect prepending (as
>>opposed to just avoiding multiple Sigs in the the presence of
>>prepending).
>> 
>> If we protect prepending, the pCNT must be carried in the protocol,
>>covered by the Sig and verified ... i.e., what you suggest below .. in
>>validation.
>> 
>> Note, that if you don't want to protect prepending ... only avoid
>>repeating sigs ..., then you don't have to carry pCNT in the protocol.
>>Just update the Sig verification algorithm treat sequences of repeated
>>AS's as one.
>> 
>> If we like the "translucent" approach to support RS, then we need to
>>carry pCNT in BGSSEC.   You are right we do need enhanced
>>receive/process rules such as:
>> 
>> Anyway, if we like this approach, we can talk the details of the
>>receiving rules / process rules to protect potential abuse.
>> 
>> dougm
>> 
>> Doug Montgomery - Manager Internet and Scalable Systems Research Group
>>/ Information Technology Laboratory / NIST
>> I like the general objective of pCNT and this seems a good idea to me.
>>My only comment at the microphone was that if we add this for
>>compression, then validation should require that pCNT MUST be equal to
>>the number of _contiguous ASx appearances in the path (i.e., no more, no
>>less, and only contiguous).
>>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Jul 2011 12:57:37 -0400

At 11:53 AM -0400 7/28/11, Doug Montgomery wrote:
>...

yes, but if you do so, then there is a signed record of that, if we 
follow Roque's suggestion and include an EKU in the router cert.  If 
contracts for resource allocation include language that prohibits 
using the RPKI to make false assertions about RS-ness, then this 
could be a basis for revocation ...

(As someone who is going through the resource allocation process with 
an RIR, I know that there are already a lot of criteria that I have 
promised to not violate, and that provide a basis for termination of 
my allocation, so this could be added to that list :-).)

Steve

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Jul 2011 13:31:11 -0400

> It's not clear to me how the system is protected from some
> unscrupulous transit provider setting their AS's to zero width, in
> order to attract more traffic.

and what is to stop them from using the transparency hack today?

randy

---

From: Highwayman <[email-masked]>
Date: Thu, 28 Jul 2011 15:07:46 -0400

> and what is to stop them from using the transparency hack today?

Not sure I see much challenge in having the bar at "anything will do, provided it's not a step back from where we are now", given where we are now :-)

Chris

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 28 Jul 2011 15:55:06 -0400

Chris, 

Do you think the proposed receiver processing rules below are insufficient?

dougm

________________________________________
From: Highwayman [[email-masked]]
Sent: Thursday, July 28, 2011 11:31 AM
To: Montgomery, Douglas
Cc: Danny McPherson; sidr wg list
Subject: Re: [sidr] pCNT & prepending

Chris

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Jul 2011 16:49:52 -0400

At 11:02 AM -0400 7/28/11, Danny McPherson wrote:
>Doug et al,
>I like the general objective of pCNT and this seems a good idea to 
>me.  My only comment at the microphone was that if we add this for 
>compression, then validation should require that pCNT MUST be equal 
>to the number of _contiguous ASx appearances in the path (i.e., no 
>more, no less, and only contiguous).
>

There is a valid secruity concern when we allow 0 as a valid pCNT value.

I think Roque's suggestion of an EKU to mark an EE cert as being 
associated with a route server is helpful here.  Yes, this is a 
self-assertion, and thus not authoritative. But, it could be a 
convenient mechanism to assist in configuration for checking when 
it's OK to receive an update with a 0 pCNT value. Specifically, if we 
agree that an ISP knows when a configured peer is an RS, then we can 
mandate that an ISP check to make sure that an update received from a 
peer with a 0 pCNT is, in fact, coming from what it believes is an 
RS. Having a marker in a cert that says "HI, I'm an RS" at least 
makes this intent clear.  (One also could imagine that, since IXPs 
are well known and the route servers at IXPs are known, a third party 
could scan the RPKI looking for certs that claim to be associated 
with RSes, and checking to see if they appear to be legit.)

BGPSEC also could mandate some configuration capabilities that enable 
ASes further along a path to filter routes based on 0 pCNT values in 
a path. For example, one might say that any AS can be configured to 
drop a route with 2 or more 0 pCNT hops in a row, or more than 2 
total, or whatever.  If we can reach agreement on any general rules 
with regard to 0 pCNT values, these rules can become part of the 
validation standard.

Steve

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 28 Jul 2011 18:21:01 -0400

> I think Roque's suggestion of an EKU to mark an EE cert as being associated with a route server is helpful here.  Yes, this is a self-assertion, and thus not authoritative.
> But, it could be a convenient mechanism to assist in configuration for checking when it's OK to receive an update with a 0 pCNT value. Specifically, if we agree that an ISP knows when a configured peer is an RS, then we can mandate that an ISP check to make sure that an update received from a peer with a 0 pCNT is, in fact, coming from what it believes is an RS. Having a marker in a cert that says "HI, I'm an RS" at least makes this intent clear.  (One also could imagine that, since IXPs are well known and the route servers at IXPs are known, a third party could scan the RPKI looking for certs that claim to be associated with RSes, and checking to see if they appear to be legit.)

About this last statement, the RIRs keep a list of IP Addresses for the IXPs, we could ask them to sign that list and include their ASN to increase the "confidence" that they really are RS. This could be checked by the validator.

Roque

> BGPSEC also could mandate some configuration capabilities that enable ASes further along a path to filter routes based on 0 pCNT values in a path. For example, one might say that any AS can be configured to drop a route with 2 or more 0 pCNT hops in a row, or more than 2 total, or whatever.  If we can reach agreement on any general rules with regard to 0 pCNT values, these rules can become part of the validation standard.
> 
> Steve

---

From: "Chris Hall" <[email-masked]>
Date: Thu, 28 Jul 2011 20:42:44 -0400

Doug Montgomery wrote (on Thu 28-Jul-2011 at 11:54 -0500);
...
> I think we would all benefit from your offer to survey the RS
> community to see if solutions that did not effect PATH_LENGTH but do
> make the RS AS# visible somewhere in the protocol (we can quibble
> about the syntax of carrying that in AS_PATH vs PATH_SIGs later).

Will do.

Chris

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Jul 2011 10:53:03 +1000

> About this last statement, the RIRs keep a list of IP Addresses for the IXPs, we could ask them to sign that list and include their ASN to increase the "confidence" that they really are RS. This co…

I am not sure that the RIRs really are appropriate reference points as to the _purpose_ to which ASes are put to use from day to day, and much the same applies to the purpose of the use of IP addresses in routing.

I suggest that if would be perhaps better to look elsewhere and even to examine the validity of the assumed need for the injection of additional mechanisms of confidence into what I would phrase as a "policy conformance" issue rather than a "detection of lying in routing" issue.

  Geoff