Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

[Borchert, Oliver (Fed)]

Yes, fine with me, ship it,
Oliver

From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: Wednesday, October 18, 2017 3:07 PM
To: Sriram, Kotikalapudi (Fed) 
Cc: Sean Turner ; Borchert, Oliver (Fed) 
; sidr@ietf.org; sidr-cha...@ietf.org; 
sidr-...@ietf.org; draft-ietf-sidr-rtr-key...@ietf.org
Subject: Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - 
Oct 16, 2017

great, so .. if everyone agrees that commentsa re dealt with I'll send this 
forward to iesg?

On Tue, Oct 17, 2017 at 4:42 PM, Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>> wrote:
>Thanks for addressing our concerns. With the new changes in place I believe it 
>is ready to advance, “ship it”

+1

Yes, thank you, Sean.
As Oliver mentioned, the comments you received from him were combined comments 
from the two us.
I have looked over the new version you sent us. Looks good to me.

When you upload an updated version, please consider including this editorial 
suggestion:
s/[RFC8205] describes gritty details,/[RFC8205] describes the details of the 
BGPsec protocol,/

Thanks.
Sriram


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

[Borchert, Oliver (Fed)]

 to the 
advanced scenarios or more generally?

[spt] Here’s how I see it: Operator has two routers each with IEEE 802.1 AR 
certificates.  They communicate the subject names (and maybe the public keys) 
from the AR certificates to the CA.  The CA then accepts requests from these 
two routers and no others.  If the operator tells the CA to give them the same 
AS number it does if not it doesn’t.  Makes sense?

10) s8 (now s9)

[spt] I’m okay with the re-write of the intro, but I kind of want to keep 
the part about it being the operator’s responsibility to maintain the key for 
their entire lifetime.

[spt] WRT another ops RFC reference are thinking about something like 
ghostbusters?  Other than that I’m not sure what else we’d refer to.

[spt] I’m happy to point to the keyroll over spec.

[spt] re mentioning BG4 fallback isn't that kind of implied with disabling 
BGPsec?  I mean guess not, but would love for you to propose some text ;)

spt
    
> On Oct 12, 2017, at 17:43, Borchert, Oliver (Fed) 
 wrote:
> 
> Hi,
>  
> I  believe this draft is important. Said that, I also believe that it 
needs some more work before it is ready to advance to IESG review.
>  
> Sriram and I were reading the draft carefully and after some discussion, 
I added our findings into the document itself.
> For easier reading, I added the comments as attachment in pdf form.
>  
> The main issues we identified were in sections 5, 6, and 8 of the 
document.
>  
> The sections 5 and 6 are not easy to understand and the flow is somewhat 
confusing. We propose to restructure the sections 5 and 6 into three sections,  
each section having a well-defined outcome.
> This makes it easier for an implementer to understand what to do and what 
is expected.
>  
> Also in section 8, we identified some overlapping with 
draft-ietf-sidrops-bgpsec-rollover-02. We propose some changes and references 
to mitigate the overlaps.
> Once our concerns are addressed, we believe that the document should 
advance to IESG.
>  
> We are willing to help out in any capacity,
>  
> Thanks,
> Oliver
>  
>  
> From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Christopher Morrow
> Sent: Monday, October 02, 2017 11:14 PM
> To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@ietf.org
> Subject: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 
- Oct 16, 2017
>  
> WG Folk,
> I thought I had sent this note our previously, but... better late then 
never sent:
> 
> Please consider this the WGLC for:
>   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-sidr-rtr-keying-13&data=02%7C01%7Coliver.borchert%40nist.gov%7Ca922cab9e2474bbfa0ec08d5143ad472%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636437165271776966&sdata=tKol0WM%2BXO3sZBx1fhBU0SnUFaV%2BnBPNQQjbYMvoe1E%3D&reserved=0
>  
> Abstract:
>   "BGPsec-speaking routers are provisioned with private keys in order to
>sign BGPsec announcements.  The corresponding public keys are
>published in the global Resource Public Key Infrastructure, enabling
>verification of BGPsec messages.  This document describes two methods
>of generating the public-private key-pairs: router-driven and
>operator-driven."
>  
> Please send along comments/complaints/issues/kudos (to the authors), to 
the list and I'll see you all in ~14 or so days.
>  
> Thanks!
> -chris
> co-chair
> 



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] RPKI-RTR implementation clues

[Borchert, Oliver (Fed)]

Hi Dennis,

The issue is not only with new BGP updates you receive during the cache update, 
the issue is also how to treat already received updates.
The safest is to operate with the RPKI state known prior the start of a cache 
update. Once the cache is updated, re-evaluate all 
BGP updates you know already using the new RPKI information.

Oliver

-Original Message-
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Ruediger Volk
Sent: Wednesday, September 27, 2017 5:54 AM
To: Denis Fondras 
Cc: r...@limes.nic.dtag.de; sidr@ietf.org
Subject: Re: [sidr] RPKI-RTR implementation clues

Hi Denis,
  > Hi,
  >
  > I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am
  > wondering about how others have implemented it.
great to hear about implementation efforts for another (nice) BGP 
implementation.

  > - How is the process started ?
  > Currently, when I start bgpd, it will fetch a list of VRP from the cache
  > and at the same time get prefixes from its peers.  As soon as it gets
  > a VRP, it will
  > try to validate prefixes in the RIB. The goal is to get a state as sooner as
  > possible to apply filters if needed.
  > The problem is I can have an unknown state in the case a prefix tries to get
  > validated while the VRP list is not complete. The solution is to make anoth 
er
  > round of validation when I get a complete VRP list.
  > Do you wait until you get a complete VRP list (ENDOFDATA message) before
  > starting the validation process ?
it is a bad idea to do origin validation based on incomplete cache state.
For example consider that a more specific (e.g. beef:dead::/32) will be 
classified INVALID if there is a matching ROA but only a covering but NOT 
matching aggregate ROA (e.g. beef::/16-16) is available before the more 
specific VRP.

  > - How are subsequent validation handled ?
  > Do you start the validation process as soon as you get a new VRP or do you 
wait
  > for a refresh timer ? In the former, a prefix could stay in the wrong state 
 for
  > some time. I am assuming that every new prefix is validated as it arrives.
Lazy origin validation classification is allowed (but it implies that besides 
unknown/valid/invalid you should support a 4th class of "unclassified"
is needed). It's great if recceived announcements are immediately classified
- but that can only be done correctly against a complete cache state.

  > Thank you in advance,
  > Denis
  >
  > ___
  > sidr mailing list
  > sidr@ietf.org
  > https://www.ietf.org/mailman/listinfo/sidr

Ruediger Volk

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Borchert, Oliver (Fed)]

Attached is the latest version of the examples. Here we added an IPv6 BGP 
update to the existing example.

Again, for better reading I attached the example as text/pdf in case the 
formatting within the email gets
Messed up.

Oliver

exampleexampleexample
Topology:

AS(64496)AS(65536)AS(65537)

Prefix Announcements: AS(64496), 192.0.2.0/24, 2001:db8::/32

For this example, the ECDSA algorithm was provided with a static k to 
make the result deterministic. 
The k used for all signature operations was taken from RFC 6979, 
chapter A.2.5 ?Signatures With SHA-256, message 'sample'?.

  k = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60

Keys of AS64496:

ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9

public key: 
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 38655612 (0x24dd67c)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-FBF0
Validity
Not Before: Jan  1 05:00:00 2017 GMT
Not After : Jul  1 05:00:00 2018 GMT
Subject: CN=ROUTER-FBF0
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
a2:5b:d3:6f:f5
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: 
Digital Signature
X509v3 Subject Key Identifier: 
AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54
X509v3 Extended Key Usage: 
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
  64496
Routing Domain Identifiers:
  inherit

Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83:
 ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1:
 02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1:
 1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29
-BEGIN CERTIFICATE-
MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU
RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw
FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU
9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN
kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF
BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k
8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x
OCRdZCk1KI3uDDgp
-END CERTIFICATE-



Keys of AS(65636):
==
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172

public key: 
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3168189942 (0xbcd6bdf6)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-
Validity
Not Before: Jan  1 05:00:00 2017 GMT
Not After : Jul  1 05:00:00 2018 GMT
Subject: CN=ROUTER-
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
b8:b5:88:f4:1f
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: 
Digital Signature
X509v3 Subject Key Identifier: 
47:F2:3B:F1:AB:2F:8A:9D:26:86:4E:BB:D8:DF:27:11:C7:44:06:EC
X509v3 Extended Key Usage: 
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
  65535
Routing Domain Id

Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Borchert, Oliver (Fed)]

Here is the updated version of the examples. I made two main modifications to 
the previous one,

(a) The Certificate is 18 month (Jan 1, 2017 – July 1, 2018)

(b) The BGPSEC Attribute type which in the reference implementations is 
currently for 
Interoperability between the QuaggaSRx and BIRD bgpsec implementations set to 
30 (0x1E) and needs to be defined by IANA (see bgpsec protocol draft).
I modified the values in the example to “**” and added an exclaimer. 

Again, for better reading I attached the example as text/pdf in case the 
formatting within the email gets
Messed up.

exampleexampleexample

Topology:

AS(64496)AS(65536)AS(65537)

Prefix Announcement: AS(64496), 192.0.2.0/24

For this example the ECDSA algorithm was provided with a static k to 
make the result deterministic. 
The k used for all signature operations was taken from RFC 6979, 
chapter A.2.5 “Signatures With SHA-256, message 'sample'”.

  k = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60

Keys of AS64496:

ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9

public key: 
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 38655612 (0x24dd67c)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-FBF0
Validity
Not Before: Jan  1 05:00:00 2017 GMT
Not After : Jul  1 05:00:00 2018 GMT
Subject: CN=ROUTER-FBF0
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
a2:5b:d3:6f:f5
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: 
Digital Signature
X509v3 Subject Key Identifier: 
AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54
X509v3 Extended Key Usage: 
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
  64496
Routing Domain Identifiers:
  inherit

Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83:
 ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1:
 02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1:
 1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29
-BEGIN CERTIFICATE-
MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU
RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw
FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU
9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN
kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF
BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k
8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x
OCRdZCk1KI3uDDgp
-END CERTIFICATE-



Keys of AS(65636):
==
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172

public key: 
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3168189942 (0xbcd6bdf6)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-
Validity
Not Before: Jan  1 05:00:00 2017 GMT
Not After : Jul  1 05:00:00 2018 GMT
Subject: CN=ROUTER-
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
b8:b5:88:f4:1f
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: 
Digital Signature
  

Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Borchert, Oliver (Fed)]

I went ahead and updated the life span of the certificates in the example.
attached please find the updated version with a certificate validity of 365 days

Oliver


On 1/12/17, 10:08 AM, "sidr on behalf of Borchert, Oliver (Fed)" 
 wrote:

Hi Randy,

The intention from my side to have the “200+ years” was based on my private 
dislike to see an example one could actually use in X years where X > now() and 
the certificate would be expired. 
Said that, this is my personal preference but I get your point. This most 
likely would set a bad example for others that might start issuing certificates 
with “infinite” life spans. 

In this regards what about a Validity of 365 days within the example. This 
seems feasible to me.

Oliver

On 1/12/17, 8:47 AM, "Randy Bush"  wrote:

> Validity
> Not Before: Jan 10 19:55:44 2017 GMT
> Not After : Oct 25 19:55:44 2290 GMT

ok, i blew it and gave no guidance in bgpsec-ops.  i guess this doc
would be as good a place as any.

of course that leaves open what lifetime to recommend.  we're not gonna
do oscp, but rather withdraw from the rpki.  so to keep from making too
much bgp noise, let me toss out O(year) to start the discussion.

i am still staring at the bgpsec message

randy


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr


Topology:

AS(64496)AS(65536)AS(65537)

Prefix Announcement: AS(64496), 192.0.2.0/24

For this example the ECDSA algorithm was provided with a static k to 
make the result deterministic. 
The k used for all signature operations was taken from RFC 6979, 
chapter A.2.5 “Signatures With SHA-256, message 'sample'”.

  k = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60

Keys of AS64496:

ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9

public key: 
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3255538383 (0xc20b92cf)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-FBF0
Validity
Not Before: Jan 12 15:17:12 2017 GMT
Not After : Jan 12 15:17:12 2018 GMT
Subject: CN=ROUTER-FBF0
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
a2:5b:d3:6f:f5
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: 
Digital Signature
X509v3 Subject Key Identifier: 
AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54
X509v3 Extended Key Usage: 
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
  64496
Routing Domain Identifiers:
  inherit

Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:6c:94:bb:32:22:3c:c7:ae:e8:e3:fd:d5:75:c2:
 74:27:fa:be:c3:ad:ba:dd:3e:4a:34:a3:c4:b7:89:65:30:64:
 02:20:2d:82:17:f4:11:97:92:df:fc:92:be:be:c6:53:bb:44:
 2d:36:83:d6:0c:95:29:47:80:85:bc:84:32:92:f7:22
-BEGIN CERTIFICATE-
MIIBiTCCATCgAwIBAgIFAMILks8wCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V
VEVSLTAwMDBGQkYwMB4XDTE3MDExMjE1MTcxMloXDTE4MDExMjE1MTcxMlowGjEY
MBYGA1UEAwwPUk9VVEVSLTAwMDBGQkYwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD
QgAEc5G6u5KgyzvhDlmxnr/7IU4EqR4MuhsTmn042Q935VqgW45pVnjg+haQS1XZ
1PXA38WIle5QvE910gWiW9Nv9aNjMGEwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSr
TZEPVcrnGiFe88r+OsxFte7BVDATBgNVHSUEDDAKBggrBgEFBQcDHjAeBggrBgEF
BQcBCAEB/wQPMA2gBzAFAgMA+/ChAgUAMAoGCCqGSM49BAMCA0cAMEQCIGyUuzIi
PMeu6OP91XXCdCf6vsOtut0+SjSjxLeJZTBkAiAtghf0EZeS3/ySvr7GU7tELTaD
1gyVKUeAhbyEMpL3Ig==
-END CERTIFICATE-



Keys of AS(65636):
==
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172

public key: 
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F

Router Key Certificat

Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Borchert, Oliver (Fed)]

Hi Randy,

The intention from my side to have the “200+ years” was based on my private 
dislike to see an example one could actually use in X years where X > now() and 
the certificate would be expired. 
Said that, this is my personal preference but I get your point. This most 
likely would set a bad example for others that might start issuing certificates 
with “infinite” life spans. 

In this regards what about a Validity of 365 days within the example. This 
seems feasible to me.

Oliver

On 1/12/17, 8:47 AM, "Randy Bush"  wrote:

> Validity
> Not Before: Jan 10 19:55:44 2017 GMT
> Not After : Oct 25 19:55:44 2290 GMT

ok, i blew it and gave no guidance in bgpsec-ops.  i guess this doc
would be as good a place as any.

of course that leaves open what lifetime to recommend.  we're not gonna
do oscp, but rather withdraw from the rpki.  so to keep from making too
much bgp noise, let me toss out O(year) to start the discussion.

i am still staring at the bgpsec message

randy


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Borchert, Oliver (Fed)]

This email contains some test vectors for draft-ietf-sidr-bgpsec-pki-algs that 
were generated as a result of IESG/author discussions; Stephen suggested that 
the draft could use some examples and he’s right so we’d like to include this 
as an IPv4 example.  In case the example is victim to some crazy line wrapping 
or for nice formatted reading, I also attached the example as text file to this 
email.

Thanks,
Oliver

snipsnipsnipsnip

Topology:

AS(64496)AS(65536)AS(65537)

Prefix Announcement: AS(64496), 192.0.2.0/24

For this example the ECDSA algorithm was provided with a static k to
make the result deterministic.
The k used for all signature operations was taken from RFC 6979,
chapter A.2.5 “Signatures With SHA-256, message 'sample'”.

  k = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60

Keys of AS64496:

ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9

public key:
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3148234511 (0xbba63f0f)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-FBF0
Validity
Not Before: Jan 10 19:55:44 2017 GMT
Not After : Oct 25 19:55:44 2290 GMT
Subject: CN=ROUTER-FBF0
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
a2:5b:d3:6f:f5
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage:
Digital Signature
X509v3 Subject Key Identifier:
AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54
X509v3 Extended Key Usage:
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
  64496
Routing Domain Identifiers:
  inherit

Signature Algorithm: ecdsa-with-SHA256
 30:46:02:21:00:cb:48:19:7a:67:fd:98:a5:0c:e3:ab:0e:59:
 fd:fb:1d:6f:6a:4c:fc:f7:e7:d7:77:3a:2c:33:82:02:57:cc:
 70:02:21:00:ea:f1:2c:08:05:b9:df:48:8f:94:8d:e0:cf:23:
 e8:8e:71:56:13:4e:44:b2:35:62:9b:cd:a1:9c:9d:04:0f:dc
-BEGIN CERTIFICATE-
MIIBjTCCATKgAwIBAgIFALumPw8wCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V
VEVSLTAwMDBGQkYwMCAXDTE3MDExMDE5NTU0NFoYDzIyOTAxMDI1MTk1NTQ0WjAa
MRgwFgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBL
VdnU9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYE
FKtNkQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsG
AQUFBwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDSQAwRgIhAMtI
GXpn/ZilDOOrDln9+x1vakz89+fXdzosM4ICV8xwAiEA6vEsCAW530iPlI3gzyPo
jnFWE05EsjVim82hnJ0ED9w=
-END CERTIFICATE-



Keys of AS(65636):
==
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172

public key:
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F

Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1572726268 (0x5dbde5fc)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-0001
Validity
Not Before: Jan 10 19:55:50 2017 GMT
Not After : Oct 25 19:55:50 2290 GMT
Subject: CN=ROUTER-0001
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
b8:b5:88:f4:1f
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage:
Digital Signature
X509v3 Subject Key Identifier:
47:F2:3B:F1:AB:2F:8A:9D:26:86:4E:BB:D8:DF:27:11:C7:44:06:EC
X509v3 Extended Key Usage:

Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[Borchert, Oliver (Fed)]

See my comments inline

On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush"  wrote:

>>> 1. It is common to use private ASNs in Confederations, 
>> but the global RPKI can’t support that.  draft-ietf-sidr-slurm seems
>> to address the issue of local management of private resources in the
>> RPKI.  …

>the issue is not how the confed AS validates ROAs of the private ASs in
>the confed.  that is trivial and supported by existing software.  my
>questions revolve around path processing.


I believe the answer to your question is found in section 7, paragraph #8 and 
following. 
There I see explanation on how to process the path using private AS numbers, 
etc.


>4.3 confuses me by using 'private' ambiguously.  i have tried to read
>that section yet again and drowned in the mass of words.  perhaps more
>coffee will help; but i am not optimistic.  i pity the implementors. 
>
>randy

Revisiting Section 4.3, I made the following observations:
In my opinion the second Paragraph explains clearly the process of the ingress 
BGPSec 
router at the confederation boundary. I believe the process described of adding 
a 
signature with pCount=0 will resolve the issue that Alvaro observed.

Said that, I feel that the explanations in paragraphs #3 and #4 are not very 
helpful. 
There I do agree with Randy's "mass of words" comment. I suggest to either 
shorten 
them or completely remove them. These two paragraphs are not needed, in 
contrary 
they might add unnecessary confusion.

When removed the following current paragraphs 5 and following do explain 
clearly the
process in the intermediate AS-members and the egress BGPSec router of the 
confederation.

In short I think paragraphs #3 and #4 disrupt the flow and are not so helpful,
so I propose to remove them.

To avoid unnecessary confusion with the ambiguity of the word private, I would 
change 
the wording of “the (private) Member-AS Number” to “the Member-AS Number” by 
removing the wording of “(private)” within parenthesis. 
This leaves the usage of private only for the signing parties private key which 
I think 
is well understood.

Oliver 

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Implementer inputs requested (Fw: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20)

[Borchert, Oliver (Fed)]

Sriram,
regarding the implementer input, here are my thoughts:

To comment 1:
==
It is not uncommon to have a length field not include its own size. An example
is the length field of the capabilities which does specify the length (size) of 
the
following capability (payload). In our case the length field specifies the 
length (size)
of the signature itself (payload) and not the total length of all the signature
fields (ski, length, signature) as do the other length fields.
In addition, adding the 2 bytes for the field itself, will add more complexity 
to the
processing regarding the crypto. Currently we can use the value “as is” without 
any
additional math applying to it which will change once we include the 2 bytes 
for the field itself.

So, I prefer to keep it as is.

To comment 2:
==
I do not believe that by sending 2 separate capabilities we really “waste” 
anything. The reason
is that compared to the overall BGP traffic, a handful of bytes exchanged 
during the session
establishment doesn’t do any harm.
But on a more serious note, introducing a 2-bit encoding adds additional 
complexity. The proposed
encoding 01 – 10 – 11 (or 1, 2, 3) is fine except that it leaves out two 
additional stages.
  (A) the encoding 00 and
  (B) no capability sent at all.

Looking at other capabilities, the “non-existence” of a capability states no 
support. Now by adding
an unused 00, what does this mean? Does it mean we don’t support the capability 
which means we have
two forms of signaling no support? And if it does not mean that, is it an error 
in which we need to add
error handling.
I think this adds unnecessary complexity that the implementer must check for 00 
and the non-existence
and deal with them the same way or differently?

To keep it simple, I prefer to keep it as it is, this way we do not add 
additional confusion:
(I)  Announce the proper capability if supported
(II)and if not supported don’t announce the capability.

This is straight forward and falls in line with other capabilities. (As Example 
MPNLRI, 4 Byte ASN, etc.)

Thanks,

Oliver


From: Kotikalapudi Sriram 
Date: Thursday, December 22, 2016 at 12:41 PM
To: sidr list 
Cc: Russ Housley , "ba...@tislabs.com" 
, Oliver Borchert , 
"sidr-cha...@ietf.org" 
Subject: Implementer inputs requested (Fw: SecDir Review of 
draft-ietf-sidr-bgpsec-protocol-20)


Russ Housley had suggested these changes (#1 and #2 below) as part of his 
SecDir review.

But he also suggested to me to put it out on the mailing list so that

implementers in particular and anyone having an opinion can have a say.



Russ's comment:

Minor:

#1

In Section 3.2, the Signature Length within the Signature Segment does

not count the length field itself.  It seems that all of the other

length values in this specification count the size of the length too.

Consistency will avoid implementation errors.

Russ's comment:

Minor:

#2

Section 2.1 says:

...  The BGP speaker

sets this bit to 0 to indicate the capability to receive BGPsec

update messages.  The BGP speaker sets this bit to 1 to indicate the

capability to send BGPsec update messages.

It seems a bit wasteful to repeat the whole capability for each

direction.  Wouldn't it be better to follow the example used in

other capability definitions (such as RFC 7911) by using one of the

unassigned bits?  The Send/Receive pair of bits would have these

semantics:

This field indicates whether the sender is (a) able to receive

BGPsec update messages from its peer (value 1), (b) able to send

BGPsec update messages to its peer (value 2), or (c) both (value 3)

for the address family identified in the AFI.

[Sriram] Observation: Two implementations exist and

they were shown to interoperate at the IETF-97 in Seoul.

The changes would cause those implementations to make code modifications.

Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Borchert, Oliver (Fed)]

Hi,

I support working group adoption,

Oliver




On 5/3/16, 5:55 AM, "sidr on behalf of Tim Bruijnzeels"  wrote:

>Hi,
>
>I believe this is useful work and support adoption. Happy to contribute to the 
>discussion where I can.
>
>Tim
>
>
>
>
>> On 02 May 2016, at 15:32, Carlos M. Martinez  wrote:
>> 
>> Hello all,
>> 
>> LACNIC has worked on three projects involving RPKI-enabling IXPs [0]. We
>> certainly support adoption of this document as a WG item and will
>> participate in the discussion.
>> 
>> Thanks!
>> 
>> -Carlos
>> 
>> [0] https://tools.ietf.org/html/draft-fmejia-opsec-origin-a-country-02
>> 
>> On 4/27/16 8:11 AM, Sandra Murphy wrote:
>>> The authors have requested working group adoption for 
>>> draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin 
>>> Validation Results from a Route-Server to Peers”.
>>> 
>>> This message starts an adoption call that will end in two weeks on 11 May 
>>> 2016.
>>> 
>>> Please respond on the list to say whether you support adoption of this work 
>>> as a working group work item AND whether you will participate in the 
>>> discussion.
>>> 
>>> Remember that working group consensus to adopt the work needs responses, 
>>> not just absence of objection, so speak up.
>>> 
>>> The draft is available at 
>>> https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01
>>> 
>>> —Sandy, speaking as one of the wg co-chairs
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-15

[Borchert, Oliver (Fed)]

Matt,

Thank you for incorporating the proposed changes regarding the Sequence of 
Octets to be Hashed. I looked over it and it looks good,

Oliver



On 3/17/16, 9:33 AM, "sidr on behalf of Sandra Murphy"  wrote:

>This starts a two week wglc for draft-ietf-sidr-bgpsec-15.  
>
>The draft is available at 
>https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-15.
>
>Please respond with your opinion of the draft’s readiness for publication.
>
>Remember that positive replies are needed, so please do provide comments to 
>the list.
>
>—Sandy, speaking as one of the wg co-chairs
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Modifiation request: draft-ietf-sidr-bgpsec-protocol-14

[Borchert, Oliver]

Sean,

The change relates to the "Sequence of Octets to be Signed" (SOS), not the 
signature blocks on the wire. 
For validation and signing, one needs to generate a separate SOS per algorithm 
/ signature block 
which is the same as it always was - nothing changed here.
The resulting signature (while signing) will be added to the appropriate 
signature block,
and algorithm transfers are still dealt with in the same manner as before.
I hope that helps.

Oliver






On 2/23/16, 10:07 PM, "Sean Turner"  wrote:

>Oliver & Michael,
>
>I see that the Algorithm Suite Identifier is now included just once, which 
>saves one byte per signature segment, and that’s great, but how’s this new 
>structure going to work if there’s an an algorithm transition?  How will you 
>support indicating the “old” and “new” algorithm?
>
>spt
>
>> On Feb 10, 2016, at 15:05, Borchert, Oliver  wrote:
>> 
>> Hello Matt,
>> 
>> after reading version 14 of the BGPSec protocol draft and after discussing 
>> the
>> update between us, Michael Baer (BIRD implementer) and I (Quagga Implementer)
>> want to propose some  changes for generation of the “Sequence of Octets to be
>> Signed” (SOS) in the draft on pg. 15. This change would modify the order of
>> information within the SOS as well as the order of attributes within the
>> “Secure_Path” Segment listed on pg. 8. 
>> 
>> For your convenience I attached this email as pdf document as well.
>>  
>> NONE of the changes has any impact on the information that is put on the wire
>> in regards to adding or removing data. The only on the wire change is the
>> ordering of the attributes within the Secure_Path Segment.
>>  
>> As we are all aware, the most expensive operation within the BGPSEC protocol 
>> is
>> the crypto operation, especially the Path verification.
>> With the proposed modification of the SOS, implementers will be able to 
>> utilize
>> more efficient and higher performing software mechanisms to validate the
>> complete chain of signatures in an update. The current form makes this more
>> difficult.
>>  
>> Our request does remove some data from the previous SOS structure, changes 
>> the
>> order of the remaining attributes within the SOS and includes the re-ordering
>> of one data segment on the wire, which will facilitate the SOS generation.
>>  
>>  
>> 1) Request for re-ordering the Secure_Path segment
>> The first request deals with modifying the order of the Secure_Path segment.
>> This modification will become more obvious later on when we explain our 
>> request
>> for changes in the structure of “Sequence of Octets to be Signed” (SOS) on
>> pg. 15. 
>> This is also the only change that has an affect on the data on the “wire” but
>> again only regarding the order itself, NOT the content.
>>  
>> The current format as it is shown on pg. 8 is as follows:
>>  
>> +---+
>> | AS Number  (4 octets) |
>> +---+
>> | pCount (1 octet)  |
>> +---+
>> | Flags  (1 octet)  |
>> +---+
>>  
>> We request to move the “AS Number” field to the end of the signature segment.
>> This results in the following structure:
>>  
>> +---+
>> | pCount (1 octet)  |
>> +---+
>> | Flags  (1 octet)  |
>> +---+
>> | AS Number  (4 octets) |
>> +---+
>>  
>> The reason for this minor change becomes more clear when we explain our 
>> request
>> for modifying the SOS structure. But as a little preview for where we want to
>> go with this, consider the following:
>>  
>> Having a set of Secure_Path segments, the last field of the following segment
>> equals the “Target AS” needed in the SOS structure. But this becomes more
>> obvious later on.
>>  
>>  
>> 2) Modifying the SOS structure”
>>  
>> The current structure as it is presented on pg. 15 of draft-14 is as follows:
>>  
>> +---+
>> | Target AS Number  |
>> +---+
>> | AS Number |
>> +---+
>> | pCount|
>> +---+
>> | Flags |
>> +---+
>> | Previous Secure_Path  |
>> +---

Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm

[Borchert, Oliver]

I support adoption and will participate in the discussion.


Oliver


On 8/27/15, 7:33 PM, "sidr on behalf of Sandra Murphy"
 wrote:

>The authors of draft-dseomn-sidr-slurm adoption have requested working
>group adoption.
>
>A working group adoption call starts now and will end 14 days from now on
>10 September.
>
>Please respond on the list to say whether you support adoption of this
>work as a working group work item AND whether you will participate in the
>discussion.
>
>Remember that working group consensus to adopt the work needs responses,
>not just absence of objection, so speak up.
>
>--Sandy, speaking as one of the wg co-chairs
>

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

[Borchert, Oliver]

I noticed Outlook changed some characters so here again:


If I understand Davids attack vector correct than the attack would look
as follows:

For the path -> A -> B -> C -> D -> E with A and D conspiring and B and C
only signing but not validating:

A signs the path to D and not to B but sends it to B. Because B and C
do not validate, just sign they forward the path to D.
D removed B and C from the path and forwards the path as -> A -> D  to E.
Now E verifies the path as valid and moves on.

If this is what David had in mind then I agree that the security guarantee
in 7.1 does not hold up.


Oliver





On 8/27/15, 3:15 PM, "sidr on behalf of Borchert, Oliver"
 wrote:

>If I understand David¹s attack vector correct than the attack would look
>as follows:
>
>For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C
>only signing but not validating:
>
>A signs the path to D and not to B but sends it to B. Because B and C
>don¹t validate, just sign they forward the path to D.
>D removed B and C from the path and forwards the path as ‹> A ‹> D  to E.
>Now E verifies the path as valid and moves on.
>
>If this is what David had in mind then I agree that the security guarantee
>in 7.1 does not hold up.
>
>
>Oliver
>
>
>
>On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein"
> wrote:
>
>>At Thu, 27 Aug 2015 15:45:49 +, Sriram, Kotikalapudi wrote:
>>> 
>>> What do you think of the following two-update collusion scenario?
>>> -- > A --> B --> C --> D --> E
>>> A and D are colluding. B and C are signing without verifying.
>>> First update at time= t0:
>>> A signs and forwards an update normally (without any corruption).
>>> The update propagates via B and C to D.
>>> D receives it and stores it, but does not forward to E (or anyone).
>>> Second update at time= t1 (= t0 + delta):
>>> A sends an intentionally corrupted version of the update (signed),
>>> while keeping the same NLRI as before.
>>> B and C are still signing but not verifying.
>>> The update propagates via B and C to D. Now D replaces
>>> this corrupted update with the earlier clean one (received at t0),
>>> and propagates to E. The resulting update from D to E is valid.
>>> One can argue that there is violation of the guarantee (in Section 7.1)
>>> at time t1. The valid route propagated from D to E does not
>>> agree with the route that B or C forwarded (at time t1)
>>> for the NLRI in consideration.
>>
>>If I understand your scenario correctly, as far as folks further along
>>the path are concerned, this is a replay attack by D.  That D is doing
>>this to cover up something bad that A is doing to B and C is almost
>>irrelevant, as is the specific nature of whatever bad thing A is doing
>>to B and C.
>>
>>So, yeah, OK, it's a form of collusion, but it's not one that relies
>>on a weakness in the signature semantics, it's one that relies on lack
>>of protection against replay attacks, something the WG discussed and
>>rejected.  Can't speak for anybody else, but I'm not particularly
>>interested in exhuming the replay horse at this late date.
>>
>>___
>>sidr mailing list
>>sidr@ietf.org
>>https://www.ietf.org/mailman/listinfo/sidr
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

[Borchert, Oliver]

If I understand David¹s attack vector correct than the attack would look
as follows:

For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C
only signing but not validating:

A signs the path to D and not to B but sends it to B. Because B and C
don¹t validate, just sign they forward the path to D.
D removed B and C from the path and forwards the path as ‹> A ‹> D  to E.
Now E verifies the path as valid and moves on.

If this is what David had in mind then I agree that the security guarantee
in 7.1 does not hold up.


Oliver



On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein"
 wrote:

>At Thu, 27 Aug 2015 15:45:49 +, Sriram, Kotikalapudi wrote:
>> 
>> What do you think of the following two-update collusion scenario?
>> -- > A --> B --> C --> D --> E
>> A and D are colluding. B and C are signing without verifying.
>> First update at time= t0:
>> A signs and forwards an update normally (without any corruption).
>> The update propagates via B and C to D.
>> D receives it and stores it, but does not forward to E (or anyone).
>> Second update at time= t1 (= t0 + delta):
>> A sends an intentionally corrupted version of the update (signed),
>> while keeping the same NLRI as before.
>> B and C are still signing but not verifying.
>> The update propagates via B and C to D. Now D replaces
>> this corrupted update with the earlier clean one (received at t0),
>> and propagates to E. The resulting update from D to E is valid.
>> One can argue that there is violation of the guarantee (in Section 7.1)
>> at time t1. The valid route propagated from D to E does not
>> agree with the route that B or C forwarded (at time t1)
>> for the NLRI in consideration.
>
>If I understand your scenario correctly, as far as folks further along
>the path are concerned, this is a replay attack by D.  That D is doing
>this to cover up something bad that A is doing to B and C is almost
>irrelevant, as is the specific nature of whatever bad thing A is doing
>to B and C.
>
>So, yeah, OK, it's a form of collusion, but it's not one that relies
>on a weakness in the signature semantics, it's one that relies on lack
>of protection against replay attacks, something the WG discussed and
>rejected.  Can't speak for anybody else, but I'm not particularly
>interested in exhuming the replay horse at this late date.
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Borchert, Oliver]

Sandy,

Yes I do believe the comments are satisfied,
Oliver

On 7/16/15 1:05 PM, "Sandra Murphy"  wrote:

>Could you please reply to the list and say whether you believe that the
>draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt version satisfies your
>comments?  It would help with the process.
>
>--Sandy
>
>On Mar 25, 2015, at 5:13 PM, "Borchert, Oliver"
> wrote:
>
>> David,
>> 
>> A correction for my previous email, I mixed up session id and serial
>> number.
>> I think to keep it simple for version 0 - 1 switches and future
>>changes, a
>> change
>> Within the session id and version id should trigger a “Cache Reset” by
>>the
>> cache
>> And the client must resynch with the server.
>> And yes, wording in this matter might need to be added - but still it
>>also
>> could
>> Be an implementation issue.
>> 
>> Oliver
>> 
>> -
>> Oliver Borchert, Computer Scientist
>> National Institute of Standards and Technology
>> (Phone) 301.975.4856 , (Fax) 301.975.6238
>> 
>> 
>> 
>> 
>> 
>> On 3/24/15, 10:58 AM, "Borchert, Oliver" 
>>wrote:
>> 
>>> Isn¹t this an implementation issue? The client either speaks 0 or 1. As
>>> long as the server
>>> keeps track of the version for the session IMHO it does not matter if
>>>the
>>> session id is
>>> shared? The client doesn¹t know about it. Lets say one encounter a new
>>>key
>>> and this
>>> Only triggers a PDU 9, the server sends send out the notification. The
>>> client can but must not
>>> React to it anyhow. If the client reacts, the server sends an end of
>>> update to a version 0
>>> session and all pdu 9 updates to a version 1 session.
>>> I don¹t see a needed wording here. Not yet but IŒm open for
>>>enlightenment.
>>> 
>>> Oliver
>>> -
>>> Oliver Borchert, Computer Scientist
>>> National Institute of Standards and Technology
>>> (Phone) 301.975.4856 , (Fax) 301.975.6238
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 3/24/15, 10:36 AM, "David Mandelberg"  wrote:
>>> 
>>>> Rob and I were talking about rpki-rtr, and I came up with another
>>>> potential issue with switching between protocol versions. I don't see
>>>> any text about whether a single session (session id and serial
>>>>numbers)
>>>> can be used for both version 0 and 1. If a router has a valid version
>>>>0
>>>> session, upgrades to version 1, and issues a serial query with the
>>>>same
>>>> session id and serial number, it's unclear what the server should do.
>>>> Could we add text to the document saying that the cache MUST maintain
>>>>a
>>>> separate session for each protocol version it supports, and a router
>>>> MUST NOT attempt to reuse session information across multiple protocol
>>>> versions?
>>>> 
>>>> --
>>>> David Eric Mandelberg / dseomn
>>>> http://david.mandelberg.org/
>>>> 
>>>> ___
>>>> sidr mailing list
>>>> sidr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Borchert, Oliver]

David,

A correction for my previous email, I mixed up session id and serial
number.
I think to keep it simple for version 0 - 1 switches and future changes, a
change
Within the session id and version id should trigger a “Cache Reset” by the
cache
And the client must resynch with the server.
And yes, wording in this matter might need to be added - but still it also
could
Be an implementation issue.

Oliver

-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238





On 3/24/15, 10:58 AM, "Borchert, Oliver"  wrote:

>Isn¹t this an implementation issue? The client either speaks 0 or 1. As
>long as the server
>keeps track of the version for the session IMHO it does not matter if the
>session id is 
>shared? The client doesn¹t know about it. Lets say one encounter a new key
>and this 
>Only triggers a PDU 9, the server sends send out the notification. The
>client can but must not
>React to it anyhow. If the client reacts, the server sends an end of
>update to a version 0
>session and all pdu 9 updates to a version 1 session.
>I don¹t see a needed wording here. Not yet but IŒm open for enlightenment.
>
>Oliver
>-
>Oliver Borchert, Computer Scientist
>National Institute of Standards and Technology
>(Phone) 301.975.4856 , (Fax) 301.975.6238
>
>
>
>
>
>On 3/24/15, 10:36 AM, "David Mandelberg"  wrote:
>
>>Rob and I were talking about rpki-rtr, and I came up with another
>>potential issue with switching between protocol versions. I don't see
>>any text about whether a single session (session id and serial numbers)
>>can be used for both version 0 and 1. If a router has a valid version 0
>>session, upgrades to version 1, and issues a serial query with the same
>>session id and serial number, it's unclear what the server should do.
>>Could we add text to the document saying that the cache MUST maintain a
>>separate session for each protocol version it supports, and a router
>>MUST NOT attempt to reuse session information across multiple protocol
>>versions?
>>
>>-- 
>>David Eric Mandelberg / dseomn
>>http://david.mandelberg.org/
>>
>>___
>>sidr mailing list
>>sidr@ietf.org
>>https://www.ietf.org/mailman/listinfo/sidr
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Borchert, Oliver]

Isn¹t this an implementation issue? The client either speaks 0 or 1. As
long as the server 
keeps track of the version for the session IMHO it does not matter if the
session id is 
shared? The client doesn¹t know about it. Lets say one encounter a new key
and this 
Only triggers a PDU 9, the server sends send out the notification. The
client can but must not
React to it anyhow. If the client reacts, the server sends an end of
update to a version 0
session and all pdu 9 updates to a version 1 session.
I don¹t see a needed wording here. Not yet but IŒm open for enlightenment.

Oliver
-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238





On 3/24/15, 10:36 AM, "David Mandelberg"  wrote:

>Rob and I were talking about rpki-rtr, and I came up with another
>potential issue with switching between protocol versions. I don't see
>any text about whether a single session (session id and serial numbers)
>can be used for both version 0 and 1. If a router has a valid version 0
>session, upgrades to version 1, and issues a serial query with the same
>session id and serial number, it's unclear what the server should do.
>Could we add text to the document saying that the cache MUST maintain a
>separate session for each protocol version it supports, and a router
>MUST NOT attempt to reuse session information across multiple protocol
>versions?
>
>-- 
>David Eric Mandelberg / dseomn
>http://david.mandelberg.org/
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] NIST BGP-SRx / QuaggaSRX Release 0.4.1

[Borchert, Oliver]

Hi all,

I wanted to announce a new release V0.4.1 of QuaggaSRx/BGP-SRx which
Adds BGPSEC path validation. QuaggaSRx is based on Quagga V0.99.22
and is available as tar ball or via 'yum'.

http://bgpsrx.antd.nist.gov

Please note that the software is still under development. If you have any
questions feel free to email me or the dev team at 
bgpsrx-...@nist.gov

Thanks,
Oliver

-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Borchert, Oliver]

I reviewed this draft and examining section 5.10 Router Key,
I noticed that the format/encoding on the wire of the key is not
specified. 
The required format/encoding of the key e.g. DER is needed to assure
a correct implementation and interoperability.

Oliver

-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wg adoption call for draft-tbruijnzeels-sidr-delta-protocol-03

[Borchert, Oliver]

I have read draft-tbruijnzeels-sidr-delta-protocol-03 and I support
adoption.


Oliver
-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238




On 1/26/15, 5:39 PM, "Sandra Murphy"  wrote:

>There are two more days to respond to this adoption call.
>
>--Sandy speaking as wg co-chair
>
>On Jan 14, 2015, at 3:38 PM, Sandra Murphy  wrote:
>
>> The authors of draft-tbruijnzeels-sidr-delta-protocol-03 have requested
>>working group adoption.
>> 
>> A working group adoption call starts now and will end 14 days from now
>>on 28 January.
>> 
>> Please respond to say whether you support adoption of this work as a
>>working group work item AND whether you will participate in the
>>discussion.
>> 
>> Remember that working group consensus to adopt the work needs
>>responses, not just absence of objection, so speak up.
>> 
>> --Sandy, speaking as one of the wg co-chairs
>

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] NIST - BGP-SRx now based on Quagga 0.99.22

[Borchert, Oliver]

For all that are interested in NIST's RPKI prefix/origin validation reference 
implementation for Quagga (BGPSRx / QuaggaSRx),
we merged the code from Quagga 0.99.16 to be based on Quagga 0.99.22.
The code is available at http://www-x.antd.nist.gov/bgpsrx

For questions or comments don't hesitate to contact us at
bgpsrx-...@nist.gov

Thanks,
Oliver

-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Announcing BGP-SRx 0.3.0 service release

[Borchert, Oliver]

This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 
Prototype Implementation.
This release includes extensive performance and robustness improvements,
multi router support, re-design/re-write of the Quagga integration,
and many bug fixes.

BGP-SRx is an open source reference implementation and research platform
for investigating emerging BGP security extensions and supporting protocols.
The BGP-SRx suite consists of three parts:
(1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API
into the Quagga router).
The focus is on origin validation, although it is designed to be extended to
path validation. Stub functionality for path validation is included in this
version.

Additionally, this release contains an SRx client/server test harnesses and a
simple RPKI validation cache simulator (VCS). The VCS allows to manually
feed ROA information into BGP-SRx server using the RPKI to Router protocol 
(rfc6810)
as well as WireShark modules for debugging.

For more information on BGP-SRx, and to download the prototype and tools, see:
http://www-x.antd.nist.gov/bgpsrx/

Comments and feedback about BGP-SRx are welcome. See the project page for 
details.

Thanks,
Oliver Borchert
-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

[Borchert, Oliver]

> On 20/03/2013 17:41, Russ White wrote:
> >
> >>What we probably need need is something that flags that a
> >> Certificate or a ROA has disappeared in the last X time. Then as
> >> operator we could take the action to decide if this was an attack or a 
> >> valid
> revocation.
> >
> > That is probably a good idea... But since the ROAs are time based
> > themselves, it might be hard to do (?).
> >
> > :-)
> 
>   Not sure if it is so hard.
> 
>   If the ROA expires because of the date is not longer valid, then there
> is normal and a high probability that there is no attack.
> 
>   Only, if the ROA is valid in the previous state and in the current is
> revoked or missing, then you will alert.
> 
> >
> > Russ
> >
> 
> /as

But what does the alert tell me? 
What if one is multi homed, uses two ROAs then switches to be single homed and 
revokes the second ROA. In this case the owner revoked the ROA and this is not 
an attack - here the alert is not of help at all!

Oliver

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] NotFound vs Uninitialized

[Borchert, Oliver]

I prefer Undefined over Uninitialized and therefore use Undefined below.

> 
> what will an operator do differently for these two shades of grey?
> 

The "Undefined" state is most likely to change shortly after assigned. If 
processed as "NotFound" and selected but validated as "Invalid" it would have 
to be withdrawn right away. A well-defined temporary state such as "Undefined" 
allows scripting policies such as "Ignore until validation state is available" 

> what is the trust difference?
> 

"FotFound" is a well-defined state within the Cache. It gives a clear answer 
about the content of the cache. It is what it is, no information found in the 
cache. 
"Undefined" on the other hand tells me that currently no cache information is 
available and I simply don't know if it is "NotFound", "Valid", or "Invalid" - 
I personally have some trouble just assuming a state.

> was this perhaps discussed extensively before?  what did the security folk
> tell us in that discussion?
> 

I don't remember this topic being discussed publicly but at NIST, we spend some 
time around this topic. And as one of the previous emails shows, at least one 
other implementation next to ours independently introduced this state.
 
> randy

Oliver
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] NotFound vs Uninitialized

[Borchert, Oliver]

On 3/13/13 1:28 PM, "Andrew Chi"  wrote:


>On 3/13/13 10:19 AM, Andrew Chi wrote:
>> Yesterday, Ruediger talked about a 4th validation state for BGP routes
>> (RFC 6811 gives only 3).  After thinking about it more, I believe it may
>> be helpful to call this validation state "Uninitialized".  Here's why.
>
>After talking to Doug and Sriram, it sounds like others already had this
>discussion using the term "Undefined."  That's probably a better word,
>since one might need it for more than just startup conditions.
>
>Should we explicitly call out this state?  Did we already decide not to?

As you correctly state Doug and Sriram, we do allow the validation state
"undefined" in our implementations BGP-Srx and QuaggaSRx. This is for the
timeframe where no information regarding the particular prefix/origin is
known or during its calculation. In our implementation for instance we
out-sorced the internal validation process into its own API - checking the
prefix-origin against the output of the validation cache outside of the
router. During this timeframe (which is a very short timeframe for origin
validation - but longer for path validation) we provide the state
"undefined" to allow the router to continue processing the update until
the final validation result is available and handed back to the router. We
added policies that can specifically deal with this situation which allows
us for instance to ignore the update until a calculated result (one of the
three specified ones) is available. But IMHO this is an implementation
specific solution and others might do it differently.

The main problem, as far as I understood it after talking to Ruediger
yesterday, is the timeframe in which the router fetches new information.
In other words the timeframe between "Serial Query" and "End of Data" -
RFC 6810. During this time new ROAS will be introduced or removed from the
router. If during this time the router reacts to each change individually
without waiting for the "big picture" of this particular
fetch/synchronization, the following problem can arise:

In case a route with a x/24 prefix has the validation result of "NotFound"
and a new ROA is introduced with a lesser specific prefix and insufficient
max length or even another ASN, this route will automatically change its
state from "NotFound" to "Invalid". If on top of this the prefix in
question belongs to the route that is selected, a withdrawal of this route
occurs.
Now an additional ROA is introduced that contains the exact x/24 prefix
including the same ASN, the route's validation state switches from
"Invalid" to "Valid" and the route will be re-selected. If the router
would have waited with its processing of the new information until all new
information are added to the system, the route never would have been
switched to "Invalid". In contrary, it would have switched right away from
"NotFound" to "Valid" without passing "Invalid" and therefore no change in
path selection would have occurred.

For this I see two solutions:
(A) The validation cache MUST send the deltas ordered from more specific
to less specific prefixes.
(B) The router does not process the new information until "End of Data"

Thinking further about (A) it would only solve the problem of a ROA
specifying the lesser specific prefixes that would invalidate the more
specific prefix but not the problem of a "same" specific prefix with a
different ASN. Here the temporary switch to "Invalid" will occur.
This leaves us with only solution (B) that requires the router to wait
until the cache update is performed (receiving "End of Data"), before
using the new information "snapshot". But to not having to wait with
calculating validation results until the update is performed, the old
"snapshot" should be used.

But this problem will not be resolved by adding a fourth state
"undefined". It is more a Best Practice kind of thing which the
implementer MUST be aware of.

Going back to the missing state "undefined", I think this is an
implementation dependent solution that actually only exists during the
time until either a validation state is calculated or during a power up or
until the FIRST "End of Data" is received from the validation cache - I
would not call it uninitialized because it also includes the time between
validation request and validation result as described earlier. This time
is short but not to neglectable, especially during table dumps.

Said that I firmly believe the state "undefined" should be added for
clarity and allowing a defined asynchronous processing of update
validation without delays of regular update-processing due to the fact of
a synchronization between router and cache. But again this could also be
only seen as too much implementation dependent.

Maybe one more information to our implementation, we allow to freely
configure our initialization state, which is by default "undefined" but
can be configured to any other state and therefore provide the operator
with a maximum on flexibilit

Re: [sidr] the need for speed

[Borchert, Oliver]

> In these use cases, what breaks if we allow two ROAs to co-exist in the 
> system (one authorizing the customer AS and one authorizing the proxy AS to 
> originate the prefix) _much before_ the attack (or storm) takes place?
After all, this is a valid business relationship. Choose your pill wisely.


Nothing will break, just think of multi-homing where two service providers 
announce the prefix out of their AS. Or just before a ROA expires a replacement 
should be installed beforehand to prevent ending up with an "invalid" during 
the origin validation.  
Again, I think it is worthwhile to mention that it takes only one ROA to 
declare the origin validation as valid.

Oliver
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] the need for speed

[Borchert, Oliver]

One solution here is that the mitigator either prepends the victims AS (works 
with "origin only") including the downside that the path is one hop longer. But 
hey, better than nothing. For origin + path validation the victim creates a 
bgpsec peering with the mitigator and signs the path. This can be done pretty 
easily I guess.
This might not be the most effective solution but IMHO it works  ;-)

Oliver
-
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology

-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy 
Bush
Sent: Tuesday, December 18, 2012 2:48 PM
To: sidr wg list
Subject: [sidr] the need for speed

I am trying to understand why our fellow engineers at Verisign are obsessed 
with global propagation of RPKI data on the order of a few minutes.  Then a 
friend hit me with the clue by four.  It's about third party DDoS (and other 
attack) mitigation.

When an NTT (just an example) customer is attacked, the customer can request 
that their upstream sink and scrub the traffic as it naturally passes through 
NTT.  NTT passes the scrubbed traffic on to the customer, and that's that.

But, when the customer's upstream does not provide such services, or the 
customer has other reasons for not using the upstream service, they can buy the 
scrubbing service from a third party, e.g. Verisign.  Verisign will announce 
the customer's prefix(es) from a Verisign AS, receive the traffic, scrub it 
clean, and send the cleaned traffic to the customer, often via a tunnel.

Well and good, except Verisign is announcing someone else's prefix, a basic 
violation of BGP origination validation.  Naturally, the customer who contracts 
to Verisign for this service issues a ROA for the
prefix(es) to the Verisign AS, and it is not a violation, all is serene.

But what if Verisign wants to take on a new customer in panic "Help, I am being 
attacked and will pay you a lot of money to fix this?"  The time for the fix is 
dependent on how quickly a new ROA for the victim's
prefix(es) can propagate.

Alternatively, the victim could pull their normal ROA(s) for their
prefix(es) and the world would get NotFound and believe Verisign's 
announcement(s).  But this too relies on quick propagation of RPKI data.

Observe that this is a problem in origin validation, i.e.  what is being 
deployed today.  The RFCs are published, the code is in the routers, ...
the horse has left the barn.

Yet another item to go into the display case of security vs. utility.
Ah well.  But I sympathize with Verisign's business case and have no desire to 
whack it.  And I assume others think similarly.

There is this little problem.  Today, the Internet has no technology for 
reliable global fast distribution of a database.  No, DNS is not the answer.  
But please have that argument on a different thread.  The only thing of which I 
am aware is Google's Spanner [0], which is a brilliant piece of work.  But it 
is not lightweight (e.g. True Time), is proprietary, is likely considered very 
secret sauce, and even Google lists it as research as opposed to beta :)

IMIHO, this is a *really* interesting area for research, though I suspect sidr 
is not the place to conduct it.  But it's research, not something we can paint 
on today.  So we are left with propagation on the order of a very few hours, 
AKA 'human time', and our discussions of how to reduce load on CAs so we can 
query them more frequently.

randy

---

[0] - http://research.google.com/archive/spanner.html
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?)

[Borchert, Oliver]

> 
> > Do I understand you correctly that you move away from your position
> > that the prefix cache sends a 1:1 image to the server as you mentioned
> > in an earlier post?
> 
> s/move away/was shoved/  :)
> 

This simplifies the implementation on the routers side. I like that ;-)

> > Therefore with the given ROAs (below):
> >  ROA1(p1 maxlen m1 valid from t0-t5) and
> >  ROA2(p1 maxlen m1 valid from t3-t9)
> >
> > Can I expect the following behavior?
> >
> > The router will receive only one Whitelist announcement for (p1 m1) at
> > or shortly after t0 followed by one Whitelist withdrawal for (p1 m1)
> > at or shortly after t9?
> >
> > Also the router will not see anything that indicates a change in ROAs
> > (ROA1 - ROA2) where the content is the same. Therefore from the
> > routers point of view only one ROA was existent during the time from
> > t0-t9.
> 
> yes, presuming t0 <= t3 <= t5 <= t9

Yes 

> and presuming the as-num is the same in both

Yes

> and presuming the prefix length is the same in both

and yes

> 
> > When do you plan to publish this change?
> 
> i could do it any time.  i guess i should.  lemme finish some big makes
> first

Sounds great

> 
> randy

Oliver
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?)

[Borchert, Oliver]

> 
> a couple of changes are actually in a yet-to-be-published rev
> 
>   o 5.5 the router is no longer expected to keep a ref count
> 
>   The cache server is responsible for assuring that it has told the
>   router client to have one and only one IPvX PDU for a unique
>   {prefix, len, max-len, asn} at any one point in time.  Should the
>   router client receive an IPvX PDU with a {prefix, len, max-len,
>   asn} identical to one it already has active, it SHOULD raise a
>   Duplicate Announcement Received error.
> 

Randy,
Do I understand you correctly that you move away from your position that the 
prefix cache sends a 1:1 image to the server as you mentioned in an earlier 
post?

Therefore with the given ROAs (below):
 ROA1(p1 maxlen m1 valid from t0-t5) and
 ROA2(p1 maxlen m1 valid from t3-t9) 

Can I expect the following behavior?

The router will receive only one Whitelist announcement for (p1 m1) at or 
shortly after t0 followed by one Whitelist withdrawal for (p1 m1) at or shortly 
after t9?

Also the router will not see anything that indicates a change in ROAs (ROA1 - 
ROA2) where the content is the same. Therefore from the routers point of view 
only one ROA was existent during the time from t0-t9.


When do you plan to publish this change?


Oliver


Oliver Borchert - Computer Scientist
National Institute of Standards and Technology
United States Department of Commerce
phone: 301-975-4856, fax: 301-975-6238
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Behavior of entities talking RPKI-Router protocol

[Borchert, Oliver]

While working on an implementation of the rpki-rtr protocol, some questions 
came up that could not be clarified using the specification draft.

(A) Unexpected withdrawal of white list (WL) entries.

   (i) What is the routers expected behavior when it receives a withdrawal of a 
white list (WL) entry that does not exist?

  (ii) Should the router respond to (A.i) by sending a "Reset Query" or should 
router silently ignore such information and if so, why?

(B) The RPKI Validation cache may contain ROA's whose Prefix/Origin content is 
identical. An example could be a ROA that is about to expire and the "follow 
up" ROA is generated in advance to prevent a down time. During a short period 
of time both would certify the Prefix/Origin content.

   (i) Should the server send a WL announcement for each instance or should the 
server reduce the information to a single WL announcement? In other words 
should the router see the announcement of the new one followed by the 
withdrawal of the old one? 

  (ii) In case the cache sends a WL announcement for each corresponding ROA 
entry can we expect the cache also to sends a WL withdrawal for each 
expired/revoked ROA?

Thanks,
Oliver


Oliver Borchert - Computer Scientist
National Institute of Standards and Technology
United States Department of Commerce
phone: 301-975-4856, fax: 301-975-6238

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr