Re: [sidr] two stranded docuemnts - stake time

[David Mandelberg]

Di, enjoy. You have my permission to take over SLURM. Let me know if
there's anything I can do to help.

On 07/22/2016 05:48 AM, Declan Ma wrote:
> Sandy & Chris,
> 
> Thank Steve for recommending me to take over SLURM. 
> 
> With David’s permission, I would be happy to assume responsibility for SLURM.
> 
> I think SLURM is quite important to RPKI operation in term of local network. 
> 
> SLURM provides a simple way to enable INR holders to establish a local, 
> customized view of the RPKI, by overriding RPKI repository data if needed.
> 
> In particular, I was exchanging notes with David earlier on the use of 
> multiple SLURM files among others, which I believe is worth more text in the 
> next version of SLURM.
> 
> Di
> 
>> 在 2016年7月21日，19:42，Stephen Kent  写道：
>>
>> Sandy & Chris,
>>
>> I believe Chris' declaration is premature.
>>
>> I anticipate that Dr. Ma may want to take over slurm, with David's 
>> permission.
>>
>> With a few minor tweaks the use cases doc can be done.
>>
>> Steve
>>
>>
>> ___
>> 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
> 


-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/



signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-slurm-01.txt

[David Mandelberg]

Hi all,

I believe this draft addresses all of the comments I've received so 
far, and is ready for WGLC. Chairs, please consider this a formal 
request.


Here's a summary of changes from the previous version:

 * In Validation Output Filtering, an origin validation assertion where 
the prefix covers the locally reserved prefix, is no longer removed from 
the RP's output. For private-use prefixes, this change shouldn't be 
significant because there are no public covering routes. For other 
prefixes (e.g., stolen/borrowed public ones), this reduces the 
likelihood of accidentally invalidating an important covering route.
 * The document is now more clear and consistent about use of SLURM 
with non-private INRs.
 * The intended status is now STD instead of BCP. (I think it was BCP 
by mistake.)

 * I removed references to LTAM because LTAM is now dead.
 * I removed references to Suspenders because I think SLURM is ready 
for WGLC and Suspenders is still an individual draft.


On 2016-04-13 17:09, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Secure Inter-Domain Routing of the 
IETF.


Title   : Simplified Local internet nUmber Resource
Management with the RPKI
Author  : David Mandelberg
Filename: draft-ietf-sidr-slurm-01.txt
Pages   : 11
Date: 2016-04-13

Abstract:
   The Resource Public Key Infrastructure (RPKI) is a global
   authorization infrastructure that allows the holder of Internet
   Number Resources (INRs) to make verifiable statements about those
   resources.  Network operators, e.g., Internet Service Providers
   (ISPs), can use the RPKI to validate BGP route origination
   assertions.  In the future, ISPs also will be able to use the RPKI 
to

   validate the path of a BGP route.  Some ISPs locally use BGP with
   private address space or private AS numbers (see RFC6890).  These
   local BGP routes cannot be verified by the global RPKI, and SHOULD 
be

   considered invalid based on the global RPKI (see RFC6491).  The
   mechanisms described below provide ISPs with a way to make local
   assertions about private (reserved) INRs while using the RPKI's
   assertions about all other INRs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-slurm-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-01


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt

[David Mandelberg]

Thanks, this addresses all the (minor) comments I sent off-list during 
WGLC. And since I realized I hadn't remembered to publicly support this, 
I'll do so now: it looks good to me.


On 2015-11-02 21:07, Sean Turner wrote:

Incorporates comments received during WGLC.

Willing to be shouted down on the tweaks in the IANA considerations
section, but I am hoping that we can move progress this version of 
the

document towards our AD.

spt


On Nov 03, 2015, at 11:03, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Secure Inter-Domain Routing Working 
Group of the IETF.


   Title   : BGPsec Algorithms, Key Formats, & Signature 
Formats

   Author  : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-12.txt
Pages   : 7
Date: 2015-11-02

Abstract:
  This document specifies the algorithms, algorithms' parameters,
  asymmetric key formats, asymmetric key size and signature format 
used
  in BGPsec (Border Gateway Protocol Security).  This document 
updates

  the Profile for Algorithms and Key Sizes for use in the Resource
  Public Key Infrastructure (draft-ietf-sidr-rfc6485bis).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-12


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] preventing SKI collisions

[David Mandelberg]

On 2015-09-16 10:38, Sean Turner wrote:

Okay so I think we’re in agreement here that we don’t work on #3 now,
but I’m also thinking that we should leave #1 and #2 alone for now.
If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then
it sounds like it's also good enough for BGPsec.  It seems really odd
that we do something different in BGPsec than what is done in the 
rest

of the RPKI.  So, I’m proposing that:


I was about to argue that BGPsec's requirements for KIs are inherently 
different than the rest of the RPKI's requirements for KIs, but then I 
realized that I only thought that way because I'm implementing the 
relying party side of things and not the BGPsec-enabled router side. So 
I now agree with you that we can leave #1 and #2 alone for now, but only 
if we do #4 (which I just made up):


4. Add text warning relying parties to detect malicious CAs that cause 
too many KI collisions, and blacklist those CAs. Similarly, warn routers 
and/or rpki-rtr caches to detect AS numbers with too many public keys 
sharing the same SKI, and blacklist those AS numbers.


In both router certs and other RPKI certs, the KIs are used as an 
optimization in the selection of a public key (BGPsec) or certificate 
(RPKI) to use for BGPsec validation (BGPsec) or certificate path 
validation (RPKI). If there are too many KI collisions, then this 
optimization stops working well, and it's possible for a malicious CA to 
DoS a router (router cert SKI collisions) or relying party (CA cert SKI 
collisions). In either case, the DoS could be prevented by reducing the 
probability of collisions (your #1-3), or by detecting and ignoring the 
malicious CA (my #4).


By the way, I think your #1 might be easier than my #4, but either one 
would prevent the issue Richard discovered.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

On 2015-09-10 15:09, Stephen Kent wrote:

At least initially, sig order was required to match the AS transit
order, to ensure that the
AS transit order is accurately represented. Is that no longer true?


Are you talking about (1) the order of the signatures on the wire, (2) 
the order of which AS path is covered by which signature, or (3) the 
chronological order in which the signatures are generated? I think Rob 
and I were talking about (3), but Rob should tell me if I misunderstood 
him.


For (1), the order needs to specified such that each signature can be 
correctly verified. Having the order of the signatures match the AS 
transit order seems like the most sensible way to do this.


For (2), I think it's critical that each signature covers that correct 
AS path, in the correct order.


For (3), the signatures will typically be generated in order, but I 
don't see the value of enforcing that. I.e., while I don't see the point 
of pre-computing signatures before including them in a BGPsec UPDATE, I 
also don't see any harm in it.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

On 2015-08-26 22:49, Rob Austein wrote:

At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote:
...
I think this problem might be fixed if we modify the protocol to 
sign

all of the preceding signed data (rather than just the immediate,
previous signature).


Agreed, assuming this means adding the (theoretically invariant)
fields from the data to be signed in section 4.1 to the data to be
signed in section 4.2.

Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's 
AS

Number" in section 4.2, this leaves the algorithm suite identifier,
the AFI, the SAFI, and the NLRI to be added to the data to be signed
in section 4.2.  I doubt that there's any practical attack based on
fiddling with the algorithm suite identifier (I'd expect any games
there to cause validation failure, end of story), but maybe somebody
has a more twisted imagination than mine, and, given that the
algorithm suite ID is one byte long, I don't think it's worth trying
to optimize that byte out of the section 4.2 signature.

Presumably we want to keep the existing signature chaining, so I
wouldn't remove anything from the data to be signed in section 4.2,
just add the fields that are currently only present in section 4.1.

David, if this is consistent with what you meant, cool, if not, say 
on.


It is not consistent with what I meant, so I'll be more explicit about 
what I meant. I meant to remove the signature chaining, and have each AS 
sign the data that is currently covered by signature chaining. I.e., 
each AS (origin or intermediary) would sign the same data structure 
(with different, but related, data in the structure):


Target AS Number (4 octets)
AS Count (4 octets)
 instances of:
AS Number (4 octets)
 instances of:
pCount (1 octet)
Flags (1 octet)
Algorithm Suite Id. (1 octet)
AFI (2 octets)
SAFI (1 octet)
NLRI (variable)

The sequence of AS Numbers is split from the sequence of (pCount, 
Flags) to preserve alignment, but the two sequences form a single 
logical sequence of (AS Number, pCount, Flags). (This could also be 
represented with 2 bytes of padding per AS, without 4-byte alignment, or 
with 3 parallel sequences; I don't really care which.) Regardless of the 
logical sequence's representation, the first (AS Number, pCount, Flags) 
entry corresponds to (Origin AS Number, pCount, Flags) from section 4.1. 
Subsequent entries correspond to (Signer's AS Number, pCount, Flags) 
from section 4.2, in order from the origin's next hop to the current 
signer.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

On 2015-08-27 15:23, Borchert, Oliver wrote:
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.


This is one type of attack that uses the issue I raised, but this 
specific attack doesn't seem problematic to me. A and D can always set 
up a BGPsec tunnel to accomplish the same result of removing B and C 
from the path, and there's not much we can do to stop that.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

On 2015-09-08 21:07, Rob Austein wrote:
Hmm, I would have thought we'd want to keep the chaining, in the 
sense

that non-originating would sign the previous signature.  I've no real
objection to signing everything else again, it's just removal of the
previous signature that I find odd here.

The benefit I see to keeping the signature chaining is that it adds 
an

ordering constraint to the signatures (signature A must have been
created after signature B), corresponding to the order in which we
expect the update to travel between signers.  This seems like a good
thing, and I don't see why we'd want to remove it.  As you've
demonstrated, it doesn't remove all possible forms of mischief, but 
it

raises the bar a bit, and it's cheap, so why not?


I agree that signature chaining provides the guarantee you stated, that 
signatures were generated in order. But in the presence of 
non-validating signers, I don't think it provides any other guarantee.


What does the guarantee about signature order provide? I don't see how 
it's useful, but I could be missing something.



Am I missing something?  Where's the benefit in removing the 
chaining?


There's no benefit to removing it, except that I don't see any benefit 
to keeping it (if we sign the full data, as I described).



--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

On 2015-09-04 13:08, Sriram, Kotikalapudi wrote:

3.  In consideration of the above (#2), the document should instead
strongly recommend that “if an AS signs an update without verifying 
first,
it SHOULD return to the update at its earliest and verify, and 
forward
a new signed update, if necessary." Make this a strong BCP 
recommendation.


Without replay protection, I don't see how this recommendation would 
help. I.e., the old signed update would still be valid.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

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

[David Mandelberg]

Hi all,

I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's 
security guarantees. Apologies that I didn't catch this earlier, before 
WGLC ended.


The security guarantee with the issue is in section 7.1, For each AS 
in the path, a BGPsec speaker authorized by the holder of the AS number 
intentionally chose (in accordance with local policy) to propagate the 
route advertisement to the subsequent AS in the path.


It appears that this guarantee will not always hold. Specifically, if 
two non-adjacent ASes conspire, and they are separated by a sequence of 
ASes that sign path data that they have not verified, then the 
conspiring ASes can violate the guarantee. The ASes that signed path 
data they didn't verify are behaving properly, since the spec says In 
particular, the BGPsec attribute SHOULD NOT be removed even in the case 
where the BGPsec update message has not been that has not successfully 
validated. I have not yet been able to come up with a practical attack 
that uses this issue to do anything particularly bad, but I am concerned 
that one might exist.


I think this problem might be fixed if we modify the protocol to sign 
all of the preceding signed data (rather than just the immediate, 
previous signature).


Thoughts?

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

[sidr] draft-dseomn-sidr-slurm adoption

[David Mandelberg]

Hi all,

As I mentioned at IETF 93, I think SLURM 
(https://tools.ietf.org/html/draft-dseomn-sidr-slurm-02) is in good 
shape for working group adoption. It's a relatively simple solution that 
supports two of the use cases from draft-ietf-sidr-lta-use-cases-03, and 
it replaces parts of draft-ietf-sidr-ltamgmt-08, which is in the process 
of being withdrawn.


Chairs, please consider this a formal request to put out an adoption 
call, as Sandy requested during the last meeting.



P.S. Does anybody know of a good soft drink distributor who could help 
me get this adopted at the beverage breaks too?


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt

[David Mandelberg]

On 2015-08-04 07:06, Sandra Murphy wrote:

Preferences for Richard’s option #2 (allow but do not mandate line
breaks) or for Richard’s option #3 (mandate line breaks)?  Note that
option #3 means we have to settle on a max line length.


I have a slight preference for #2 since it probably requires the least 
total work. If somebody down the road really can't handle lines longer 
than X columns, locally re-wrapping lines in a TAL is really easy to do 
in many text editors or scripting languages.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] Last Call: draft-ietf-sidr-rfc6490-bis-04.txt (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard

[David Mandelberg]

On 2015-07-29 20:52, Richard Hansen wrote:
I misread the MIME RFC; it requires line breaks every 76 characters, 
not

every 75.  So I think 76 is a better choice.


For what it's worth, here are line lengths from an assortment of TALs I 
had lying around.


afrinic.tal: 64
apnic-rpki-root-afrinic-origin.tal: 64
apnic-rpki-root-arin-origin.tal: 64
apnic-rpki-root-iana-origin.tal: 64
apnic-rpki-root-lacnic-origin.tal: 64
apnic-rpki-root-ripe-origin.tal: 64
arin.tal: 80
lacnic.tal: 64
ripe-ncc-root.tal: 55
ripe-pilot.tal: 78

Of these, one production TAL (arin.tal) and one non-production TAL 
(ripe-pilot.tal) are longer than 76. However, TALs are generally only 
used locally, and re-wrapping text is rather easy. So I don't think the 
existing TALs should have too large of an impact on whatever decision we 
make.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

[David Mandelberg]

On 2015-06-19 14:00, Sandra Murphy wrote:

Anyone who commented on  draft-ietf-sidr-bgpsec-protocol-11.txt is
encouraged to review this version and report if your comments have or
have not been addressed.


My comments have been addressed, but I have some questions about the 
way one of them was addressed:


Is the MP_REACH_NLRI encoded with or without the attribute flags and 
type code?


Don't the values of MP_REACH_NLRI's Length of Next Hop Network 
Address and Network Address of Next Hop change with each hop, making 
it infeasible for remote ASes to verify the origin's signature?


MP_REACH_NLRI has a reserved field that MUST be set to 0, and SHOULD 
be ignored upon receipt. If a BGPsec speaker receives an update where 
reserved is non-zero, what should it do? With the current text, I could 
interpret SHOULD be ignored upon receipt as meaning either calculate 
the signature using the reserved field as received or calculate the 
signature using all zeroes in place of the reserved field.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

On 2015-06-12 15:34, Rob Austein wrote:

At Tue, 17 Mar 2015 00:46:23 -0400, David Mandelberg wrote:
The Router Key PDU (section 5.10) uses a fixed-size field for the 
SKI.
What's the plan for algorithm agility, if the size of the SKI 
changes?

if the size of the SKI does not change, but the algorithm does?


I'm gonna weasel on this one and say

a) A SKI is a SKI and it's none of this protocol's business how it's
   calculated, so we don't care about algorithm changes per se here,
   only about the length; and


Agreed.



b) If and when the SKI length changes, we redesign the PDU and bump
   the version number.

The alternative would be to add a SKI-Length field or some such,
either in the reserved (zero) field just after the flags field, or
just after the PDU length field.


If it wouldn't hold anything up too much, I'd prefer adding a 
SKI-Length field now. On the other hand, if adding that field would 
significantly delay this document, then I won't push it. It just seems 
strange to me that any future decision to change the length of the SKI 
will also require changing the the rpki-rtr version.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt

[David Mandelberg]

On 2015-06-02 14:40, Stephen Kent wrote:

Also, I'm curious ton know whether RPs are
ignoring LFs or
if they assumed the formatting was purely an artifact of RFC
publication  constraints.


All of the TALs I've ever seen have had line breaks in the Base64. I 
haven't checked if they're CRLF or LF. Rpstir ignores either type of 
line break within the Base64.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

[sidr] extensions in RFC6487 but not draft-ietf-sidr-bgpsec-pki-profiles-10

[David Mandelberg]

Hi,

There's some text in draft-ietf-sidr-bgpsec-pki-profiles-10 sections 
3.1 and 3.1.3 that I found confusing. For reference,


https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-10#section-3.1:

   This profile is also based on [RFC6487] and
   only the differences between this profile and the profile in
   [RFC6487] are listed.

https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-10#section-3.1.3:

   The following X.509 V3 extensions MUST be present (or MUST be 
absent,
   if so stated) in a conforming BGPSEC Router Certificate, except 
where

   explicitly noted otherwise.  No other extensions are allowed in a
   conforming BGPSEC Router Certificate.

I checked with the authors, and the intent was that the following 
refers to all extensions in RFC6487 and the updates to extensions in 
draft-ietf-sidr-bgpsec-pki-profiles-10. However, I initially read the 
text in 3.1.3 as forbidding all extensions not mentioned in 
draft-ietf-sidr-bgpsec-pki-profiles-10, including some useful ones like 
the SKI.


I think it might be clearer to simply remove the entire first paragraph 
of section 3.1.3. RFC 6487 section 4.8 contains similar[0] text, and 
section 3.1 of the draft makes it clear that RFC 6487 section 4.8 
applies.


 [0] But not the same. That issue should probably be handled by 
draft-rhansen-sidr-rfc6487bis though.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg]

On 2015-04-28 15:21, Iljitsch van Beijnum wrote:

On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia)
rogag...@cisco.com wrote:

It is not an implementation choice, it is by design. If a signed 
object does not validate (based on whatever reason not just 
expiration), it is like if did not existed.


No...

Suppose:

ROA: 193.0.0.0/21 up to /21 - AS  not valid after 20150430


In your example, is this the only ROA with a prefix that covers 
193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below, 
I'm assuming it is. Please correct me if I'm wrong.




BGP table 29 april:

193.0.0.0/21    - valid
193.0.0.0/21    - invalid
193.0.7.0/24    - invalid
192.0.0.0/16    - unknown


This part looks right to me.



But, two days later, after the ROA expires, do we have this:

193.0.0.0/21    - unknown
193.0.0.0/21    - unknown
193.0.7.0/24    - unknown
192.0.0.0/16    - unknown

or this:

193.0.0.0/21    - invalid
193.0.0.0/21    - invalid
193.0.7.0/24    - invalid
192.0.0.0/16    - unknown

?

[snip]

But the real issue is that this isn't written down anywhere as far as
I can tell, so we're dependent on implementers all independently
coming up with the preferred way to handle this. That's never good
business for a standards organization.


It's the first one (all unknowns). I don't think this is written down 
explicitly, but if implementations follow RFC6483, I don't think there's 
any way they can get the second result.


From RFC6483, Section 2:

   It is assumed here that a relying party (RP) has access to a local
   cache of the complete set of valid ROAs when performing validation 
of

   a route.  (Valid ROAs are defined as ROAs that are determined to be
   syntactically correct and are signed using a signature that can be
   verified using the RPKI, as described in [RFC6482].)  The RP needs 
to

   match a route to one or more valid candidate ROAs in order to
   determine a validation outcome, which, in turn, can be used to
   determine the appropriate local actions to perform on the route.

This means that only valid (non-expired) ROAs are used for origin 
validation. Like Roque said, if a signed object does not validate 
(based on whatever reason not just expiration), it is like if did not 
existed.


Then, in the next paragraph:

   However, routes
   for address prefixes that are not fully described by any single ROA
   (i.e., those routes whose address prefixes may be an aggregate of
   address prefixes described in a valid ROA, or have address prefixes
   where there is no intersection with any valid ROA), and are not
   matched by any valid ROA and do not have an address prefix that is a
   more specific address prefix described in any valid ROA, cannot be
   reliably classified as invalid in a partial deployment scenario.
   Such routes have a validation outcome of unknown.

Since the {AS , 193.0.0.0/21-21} ROA expired, there's no *valid* 
ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24, 
192.0.0.0/16}. (See my assumption above about no other ROAs for these 
prefixes.) Since none of these four prefixes intersect any prefix in any 
valid ROA, all four routes you gave are unknown.


Based on the two snippets above, I do think it's clear enough for 
implementations to get it right. However, you asked a good question that 
other people will probably ask again. Do you think it would be helpful 
to make this case more explicit somewhere?


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

On 04/01/2015 01:38 AM, Randy Bush wrote:
 why are you trying to rescue the case where a router (or cache) upgrades
 versions in the middle of a session?
   o upgrade should be very rare
   o reload is relatively cheap
   o and you are generating kinky corner cases to patch it
 
 session reset.

I wasn't trying to rescue it, I was trying to ensure a session reset.

 the bloody router (or cache) will have reloaded anyway
 and does not have the old state.

Either end can upgrade to support version 1 before the other is ready;
version 1 is only negotiated after both ends support it. I know that our
cache implementation does not lose state unless the database is manually
cleared, but I can't speak for other cache or router implementations. I
agree that the simplest way to fix this issue is to require a reset
query when a new version is negotiated, but I don't think that can be
done by relying on state being lost.

For reference, here's the text that I originally proposed:

   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.

If one of those requirements is too burdensome, either of them would be
sufficient by itself to ensure that a reset query happens when the
negotiated protocol version changes.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/



signature.asc
Description: OpenPGP digital signature
___
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

[David Mandelberg]

On 2015-04-01 12:39, Randy Bush wrote:

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.


why should there ever be two versions running at the same time 
between a

cache and a router?


For any pair of (cache, router), there would only be one version at a 
time. As I understand it though, a cache can use the same session 
information for all of its routers, which may not all use the same 
version.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

On 2015-04-01 14:21, Rob Austein wrote:
David, I think a simpler way to express the semantics you want is 
just

to consider the protocol version number to be part of the session
identifier.  That way, a version 0 session can never match a version 
1

session, by definition, full stop.


Sure, that works. (BTW, I think Oliver also came up with something 
similar.)


Alternatively, how about this? ;)

Routers and caches SHOULD CONSIDER [RFC6919] the implications of 
serial queries across protocol versions.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt

[David Mandelberg]

Hi,

While thinking about RRDP (draft-ietf-sidr-delta-protocol-00), I 
realized that there's a minor conflict between RRDP's push to transition 
from rsync to http(s), and the TAL format's requirement to use only 
rsync URIs. I propose the below changes to 
draft-ietf-sidr-rfc6490-bis-03 to make RRDP's work easier in the future 
without causing any harm now. Sorry to bring this up so late in the 
process for draft-ietf-sidr-rfc6490-bis.



In the abstract, change:

   This document obsoletes RFC 6490 by adding support for multiple URIs 
in a TAL.


to:

   This document obsoletes RFC 6490 by adding support for multiple URIs 
in a TAL, and allowing URI schemes other than rsync.



In section 2.1, change:

   where the URI section is comprised of one of more of the ordered
   sequence of:


  1.1)  an rsync URI [RFC5781],

  1.2)  a CRLF or LF line break.

to:

   where the URI section is comprised of one of more of the ordered
   sequence of:


  1.1)  a URI [RFC3986],

  1.2)  a CRLF or LF line break.

   The URI section MUST include one or more rsync URIs [RFC5781]. 
Non-rsync URIs MAY be present.


I assume that an rfc3986 URI cannot include either CRLF or LF, but 
if I'm wrong then I'd like to add a MUST NOT somewhere in this text.



In section 2.2, change:

   Each rsync URI in the TAL MUST reference a single object.

to:

   Each URI in the TAL MUST reference a single object.

and:

   Where the TAL contains two or more rsync URIs, then the same self-
   signed CA certificate MUST be found at each referenced location.  In
   order to operational increase resilience, it is RECOMMENDED that the
   domain name parts of each of these URIs resolve to distinct IP
   addresses that are used by a diverse set of repository publication
   points, and these IP addresses be included in distinct Route
   Origination Authorizations (ROAs) objects signed by different CAs.

to:


   Where the TAL contains two or more URIs, then the same self-
   signed CA certificate MUST be found at each referenced object.  In
   order to increase operational resilience, it is RECOMMENDED that
   no two URLs which share a scheme have domain name parts that can
   resolve to the same IP address. Additionally, it is RECOMMENDED that
   these IP addresses be included in distinct Route
   Origination Authorizations (ROAs) objects signed by different CAs.


In section 3, add this paragraph at the beginning:

   An RP MUST support the rsync URI scheme and MAY support additional
   URI schemes. An RP SHOULD ignore all URIs with unsupported schemes.

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

On 2015-03-25 16:13, Borchert, Oliver wrote:

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.


If the router sends a serial query, yes I agree.

And yes, wording in this matter might need to be added - but still it 
also

could
Be an implementation issue.


After talking with you in Dallas, I agree that we should try to give 
implementors some leeway here. I still think there's an issue to address 
though. Here's the case I want to prevent:


1. Router has all the data for version 0, session X, serial Y.
2. Router upgrades to version 1, disconnects, reconnects, and sends a 
serial query with version = 1, session = X, and serial = Y.
3. Cache replies with all the changes from (1, X, Y) to (1, X, Y+1), 
instead of from (0, X, Y) to (1, X, Y+1).


As you pointed out in person, one way to avoid this is for the cache to 
give each router a different session ID and track which version is used 
by each router. Then the cache can respond in step 3 with the changes 
from (0, X, Y) to (1, X, Y+1). Another way to avoid this is the first 
part of what I originally suggested: effectively requiring the cache to 
respond with a cache reset in step 3. Or the second part of what I 
suggested: requiring the router to issue a reset query instead of a 
serial query in step 2. I'm having trouble coming up with *simple* text 
that prevents the issue while allowing any solution. If you can think of 
something, that would be great. Otherwise, I'd prefer to at least pick 
one of the solutions that does not require a cache to track its routers 
individually.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

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

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

[David Mandelberg]

On 2015-03-17 14:29, George, Wes wrote:

This
may be as simple as recommending that in the case where data from 
multiple

caches is held and specific entries conflict with one another, there
SHOULD be an odd number of caches so that there is basis for 
comparison to
determine which cache is out of sync or providing incorrect info. 
(i.e.

Have 3 so that you can go with the 2/3 that agree)


Are you suggesting comparison of all the data from each single cache as 
an atomic entity, or comparison of individual IPvX and Router Key PDUs?


If the former, then I think that would work fine as long as a majority 
(or maybe even a plurality) of the caches has the exact same data. But 
what does the router do if this is not the case? If the caches all 
download from the RPKI at different times, then I would expect it to be 
common for no two caches to have the same data.


If the latter, then the semantics depend heavily on exactly how the 
comparison is done. Lets say a CA simultaneously issues one ROA for {AS 
65536, 10.0.0.0/8} and another for {AS 65537, 10.0.0.0/8}. Some of the 
caches see the publication point before both ROAs are issued; some see 
the pub point after both ROAs are issued and published. Can you 
guarantee that the voting mechanism will always result in either both 
ROA payloads, or neither, being used? (If a router ends up using one but 
not the other, then a previously unknown route becomes invalid.)


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

___
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

[David Mandelberg]

On 2015-03-06 05:22, Sandra Murphy wrote:

Please comment to the list whether you believe that this draft is
ready for publication.


I reviewed this draft. My substantive comments are below, and I'll send 
nits to the authors. Other than the below and the comment that Tim B 
sent to the list, I think the draft is ready for publication. (Note that 
while I have written a cache implementation of version 0 of this 
protocol, I have not yet written an implementation of version 1.)


Section 5 says Fields with unspecified content MUST be zero on 
transmission and MAY be ignored on receipt and Section 5.1 says Fields 
shown as zero or reserved MUST be zero.  The value of such a field MUST 
be ignored on receipt. Are there three separate things (unspecified, 
zero, and reserved) to which these different rules apply? Or are these 
all the same thing, and the MAY in the first quote conflicts with the 
second MUST in the second quote?


The Router Key PDU (section 5.10) uses a fixed-size field for the SKI. 
What's the plan for algorithm agility, if the size of the SKI changes? 
if the size of the SKI does not change, but the algorithm does?


Section 7 adds the requirement that A router MUST start each transport 
session by issuing either a Reset Query or a Serial Query. However, I 
don't see an additional requirement that the cache can't start sending 
PDUs (e.g., a Serial Notify) before it receives a Query from the router. 
Maybe there should be? Our current (version 0) implementation sends a 
Serial Notify whenever there is a new serial number, even if the router 
has not yet made any queries. If a version 1 router connects to our 
version 0 cache and we somehow manage to send a Serial Notify before the 
router is able to send a Query, what should the router do? Likewise, 
what should the router do if it receives any version 1 PDU before it has 
sent a Query?


What happens if version 1 is successfully negotiated, but a later PDU 
is sent (in either direction) with its version set to 0? Should the 
receiving side send an Error Report and disconnect? Likewise, what 
happens if version 0 is successfully negotiated, but a later PDU has a 
version of 1? Should the receiving side send an Error Report and 
disconnect? Even if the version 1 PDU is a Query (router to cache) and 
the cache supports version 1? I have no issue with disallowing 
re-negotiation of the protocol version, but I think it should be clearly 
specified that negotiation happens only at the beginning of a transport 
session.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg]

On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote:
 I agree that the solution should not merely rely on the presence of a 
 validating ROA.
 But there is some more detail here that is worth looking into. The path was 
 fully signed 
 and assume all signatures are valid. Then clearly the origin AS actually 
 announced it.
 The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4) or 
 102::/16 (v6)?
 The ROA has AFI information, but the signed update does not (currently).
  https://tools.ietf.org/html/rfc6482#section-3.3   
 “Within the ROAIPAddressFamily structure, addressFamily contains the
 Address Family Identifier (AFI) of an IP address family.  This
 specification only supports IPv4 and IPv6.  Therefore, addressFamily
 MUST be either 0001 or 0002.” 
 
 Hence, as Keyur has surmised, there is a possibility that the ROA can help 
 resolve the ambiguity here.
 But the ambiguity would still persist if the same origin AS happens to have 
 ROA(s) for 
 both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6)  (though the probability is 
 extremely small).
 So, yes, a robust solution calls for something more than a validating ROA.
 The ambiguity goes away if the AFI (of the announced prefix) is included by 
 the origin AS 
 on the wire as well as in the sequence of octets that are signed.

When there's no attack, I don't think there's any ambiguity about what
NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs
in the right places on the wire. The only change that I think needs to
happen for this issue is including (S)AFIs in the data that's signed.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/



signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg]

All, while coming up with the example below, I realized another issue.
The structure in 4.1 doesn't include an Address Family Identifier.
Unless I missed something, this means that a signature for 1.2.0.0/16
would be exactly the same as a signature for 102::/16. This would be a
much more practical attack than the one I originally though of.

Michael, response to your comment is below.

On 02/10/2015 12:09 PM, Michael Baer wrote:
 I don't believe this is a problem.  The signature is calculated by
 creating a digest of the data and then creating a signature from that
 digest.  I'm definitely not a cryptography expert, but my understanding
 of digest functions generally is that with even slightly differing
 input, the resulting set of bits should be completely different.
 Assuming the digest function chosen is not flawed, there shouldn't be a
 set of bits from the digest of 4.1 that could be used to successfully
 replace the digest of 4.2, except by chance.

You're right about digest algorithms being highly sensitive to changes
in the input, but the issue I described is when the two inputs are
equal, not just similar. For example, if a router signed the below
values in the structure from 4.2:

Target AS Number = 0x01020304
Origin AS Number = 0x05060708
pCount = 0x01
Flags = 0x00
Most Recent Sig Field = 0x00700102030405060708090a0b0c0d0e (See Sriram's
email for why this would never actually happen with the current
algorithm suite's signature length.)

Then the router signed the digest of the bytes
0x010203040506070801700102030405060708090a0b0c0d0e. However, these
exact same bytes could appear to have come from the structure in 4.1
with these values:

Target AS Number = 0x01020304
Origin AS Number = 0x05060708
pCount = 0x01
Flags = 0x00
Algorithm Suite Id = 0x00
NLRI Length = 0x70 (112 bits = 14 bytes)
NLRI Prefix = 0x0102030405060708090a0b0c0d0e

Note that the first 16 bits of 4.2's Most Recent Sig Field can't be any
values. The first 8 have to match the Algorithm Suite ID (1 possible
value). The next 8 have to be a valid number of bits for the number of
bytes in the prefix (8 possible values). This means that there's only a
2^-13 chance that a single random Most Recent Sig Field of the
appropriate length could be reinterpreted successfully. However, with
more than 2^13 signatures floating around the Internet, that's not good
odds.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/



signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg]

On 2015-02-07 18:28, Sriram, Kotikalapudi wrote:
It might be possible for an attacker to take a valid signature of 
data from the structure in 4.2,
and present it as a valid signature of the same bytes interpreted 
with the structure in 4.1.


If you have worked out a concrete example showing how the attack 
works,

it would be good to see that. For this type of attack to be feasible,
is it required that the size
of the signature field equals the combined size of {Alg. ID, NLRI
length, NLRI prefix}?


Yes, that's correct.


If yes, observe that the size of the signature field (ECDSA-P256) =
64 octets + a few variable #octets,
and the combined size of {Alg. ID, NLRI length, NLRI prefix} is
either 6 octets (IPv4) or 18 octets (IPv6).


Good catch. It seems that for a feasible attack, a future algorithm 
suite would need to have much shorter signatures (unlikely) or bgpsec 
would need to be extended to something with much longer NLRI prefixes 
(who's ready for IPv8?!) So this isn't going to bite us for a very long 
time, if ever. Should we (1) prevent that remote possibility by adding a 
single byte to both to-be-signed structures (which doesn't add any bytes 
on the wire), (2) make a note in the security considerations, or (3) 
just ignore this as too unlikely to care about? If we choose either 2 or 
3, won't it be very difficult to change our minds once bgpsec is 
deployed? How hard is it to do (1) now?


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg]

After reviewing this document, I have one concern below, and some nits 
that I'll send to the editor. Otherwise it looks good to me.


In sections 4.1 and 4.2, there are two different to-be-signed 
structures. If I understand correctly, the same router keys will be used 
to sign data from both structures. It might be possible for an attacker 
to take a valid signature of data from the structure in 4.2, and present 
it as a valid signature of the same bytes interpreted with the structure 
in 4.1. I'm not sure anything malicious could be done this way, but 
reinterpreting the meaning of signed data seems like a bad idea to me. 
It would be easy to prevent this by prepending both structures with a 
single byte that MUST BE 0 for 4.1 and MUST BE 1 for 4.2. Apologies if 
this has already been discussed and is not an issue.


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] this is possibly Tim Bruijnzeels delta protocol

[David Mandelberg]

Yes, I know I'm an author, but I'm going to review this anyway.

Section 3.2.3: The serial attribute must be an unbounded, unsigned 
positive integer indicating the current version of the repository. On 
the relying party side, unbounded integers make me a bit nervous. If the 
serial number is terabytes long, I'd really prefer to reject the entire 
file. Can we instead restrict the serial attribute to fit in a 64-bit 
unsigned integer? Changing sessions once every 2^64-1 serials doesn't 
seem like a significant burden.


(nit) Section 3.2.4 uses the term version when I think it means 
serial.


In section 3.2.5, A new delta file MUST be generated, but The 
[notification] file SHOULD also include available delta files for this 
and previous updates. Is there any point to generating a delta file and 
not listing it in the notification file? I'd recommend changing both to 
MUST or both to SHOULD.


Section 3.4.3: Including the hashes in this manner allows relying 
parties to identify specific objects by their hash rather than the URI 
where they are found. If some RPs use just the URI and some use just 
the hash, it might be possible for a cooperating CA and repository to 
cause the two types of RP to see two completely different views of the 
RPKI. A paranoid RP could check both the hashes and the URIs to make 
sure that never happens, but that defeats the purpose of having both 
identifiers. Is the flexibility here worth the potential risk?


--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

[David Mandelberg]

On 2014-03-07 06:39, Rob Austein wrote:

David can speak for himself, but speaking on my own behalf as a
implementer: if we define a canonical order, comparing two PDUs is a
simple binary string comparison.  If we don't define a canonical
order, comparison is more complicated, hence more error-prone.  Given
that the rpki-rtr protocol requires duplicate elimination, we do need
to perform such comparisons, so making them as simple as possible
seems advisable.


I fully agree with the above.



FWIW, I think David's suggestion is a good one, and I'm likely to
implement it that way in my server whether required to do so or not.


I'll probably also implement it that way.

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] Man-in-the-middle attack

[David Mandelberg]

On 2014-03-03 16:08, Demian Rosenkranz wrote:
 ... a EE certificate, the rp software would recognize it, because the
 corresponding signed object can't be validated.

An EE certificate used for a CMS signed object (e.g., a ROAs) is 
embedded in the CMS signed object itself. I.e., the EE certificate is 
not a separate file that a MITM could omit or delete. An rsync MITM 
could modify the CMS to not include an EE certificate, but we'd reject 
that as an invalid CMS object. Also, the hash of the CMS object would no 
longer match its corresponding hash in the manifest.


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

Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

[David Mandelberg]

I support adoption, and I have a few comments/questions about the draft:

In section 5.8, you mention an Update Query PDU. Did you mean Reset Query?

In section 5.10, could you move the SKI to before the AS numbers so all 
the fixed-length fields are at the beginning?


(nit) In section 10, s/pointer of presence/point of presence/

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

[sidr] rpstir-0.10 released

[David Mandelberg]

Hi all,

We just released version 0.10 of our relying party software, rpstir. The
biggest changes are beta support for both 64-bit mode and Mac OS X. Full
ChangeLog and download link below:

* Add beta support for running rpstir in 64-bit mode.
* Add beta support for running rpstir on Mac OS X.
* Significantly improve performance of incremental updates by 
adding an

  rsync flag to preserve file modification times.
* Fix multiple potential SQL-injection bugs.
* Support newer versions of rsync and automake.
* Remove support for RPSL due to lack of demand.
* Update conformance cases (see doc/conformance-cases).
* The ./configure script no longer prints a misleading error 
message

  when it's run outside of a git directory.
* Add tests with AS numbers that don't fit into 16 bits.
* Reject trust anchor CA certificates that have resources marked
  inherit, as specified in RFC 6490, Section 2.2.
* Verify that rpstir compiles with clang, and fix all of clang's
  warnings.
* In the statistics collection mode, add support for 
incremental updates

  and for running multiple simultaneous statistics collections.
* Change handling of CRLs that list syntactically invalid serial
  numbers. These CRLs are now accepted, but the certificates with
  syntactically invalid serial numbers are still not accepted.


Download: https://sourceforge.net/projects/rpstir/
Contact: rpstir-supp...@bbn.com

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

[sidr] Fwd: New Version Notification for draft-dseomn-sidr-slurm-00.txt

[David Mandelberg]

Here's the SLURM document that I previously mentioned. Drink up :)

On 2014-02-06 13:53, David Mandelberg wrote:

I'm working on a new draft called SLURM (Simplified Local internet
nUmber Resource Management) that I hope to have out before the cutoff
next week. I'm pretty sure it handles Bob's use case, and I think it
could also handle Alice's use case if I understand that case
correctly.


 Original Message 
Subject: New Version Notification for draft-dseomn-sidr-slurm-00.txt
Date: 2014-02-10 17:00
From: internet-dra...@ietf.org
To: David Mandelberg da...@mandelberg.org, David Mandelberg 
da...@mandelberg.org



A new version of I-D, draft-dseomn-sidr-slurm-00.txt
has been successfully submitted by David Mandelberg and posted to the
IETF repository.

Name:   draft-dseomn-sidr-slurm
Revision:   00
Title:		Simplified Local internet nUmber Resource Management with the 
RPKI

Document date:  2014-02-10
Group:  Individual Submission
Pages:  7
URL:
http://www.ietf.org/internet-drafts/draft-dseomn-sidr-slurm-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-dseomn-sidr-slurm/

Htmlized:   http://tools.ietf.org/html/draft-dseomn-sidr-slurm-00


Abstract:
   The Resource Public Key Infrastructure (RPKI) is a global
   authorization infrastructure that allows the holder of Internet
   Number Resources (INRs) to make verifiable statements about those
   resources.  Internet Service Providers (ISPs) can use the RPKI to
   validate BGP route origination assertions.  Some ISPs locally use 
BGP

   with private address space or private AS numbers (see RFC6890).
   These local BGP routes cannot be verified by the global RPKI, and
   SHOULD be considered invalid based on the global RPKI (see RFC6491).
   The mechanisms described below provide ISPs with a way to make local
   assertions about private (reserved) INRs while using the RPKI's
   assertions about all other INRs.




Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

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

Re: [sidr] FW: I-D Action: draft-ietf-sidr-lta-use-cases-00.txt

[David Mandelberg]

On 2014-02-05 21:12, Randy Bush wrote:

The lta-use-cases draft was motivated as a way to start/guide
discussion of the Local Trust Anchor Management draft and the
Suspenders draft.

The question is whether we need both efforts, or only one, and if 
so,

which one.


if you accept the three cases of the use cases draft, you may be left
thinking that neither ltam nor suspenders meets the needs.  it's all
about roas, certs are incidental.


I think Suspenders meets Carol's use case. Carol could publish a LOCK 
and INRD as a precautionary measure. Then when the Dutch court attacks, 
relying parties that use Suspenders would detect the attack and could 
continue to route to Carol.


I'm working on a new draft called SLURM (Simplified Local internet 
nUmber Resource Management) that I hope to have out before the cutoff 
next week. I'm pretty sure it handles Bob's use case, and I think it 
could also handle Alice's use case if I understand that case correctly.




--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] rpstir-0.7 released

[David Mandelberg]

Hi all,

We just released version 0.7 of our relying party software, rpstir. This
version is primarily a bugfix release with fixes for bugs we found at
the relying party testing session at IETF 86.

Download: https://sourceforge.net/projects/rpstir/
Contact: rpstir-supp...@bbn.com

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

Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)

[David Mandelberg]

Overall this looks good. I found one minor issue and a bunch of nits,
and I have some questions:


= minor =

4.6.7. Notification of Certificate Issuance by the CA to Other Entities:
There is no section 4.4.3.


= questions =

1.5.1. Organization administering the document: Should the address
and/or website of the organization also be included? That could help
disambiguate when there are multiple organizations with the same or
similar names.

4.1.2. Enrollment Process and Responsibilities: I found the second
sentence unclear. Are you trying to tell registries and ISPs that
certificates should be issued as part of their normal business
practices? Are you trying to say that *if* certificates are issued as
part of normal business practices *then* a separate application to
request a certificate may not be necessary?

4.6.1. Circumstance for Certificate Renewal: The phrase unless the
private key has been reported as compromised doesn't specify how a
compromised key can be reported. Should there be a reference to section
4.9.3?

4.7.1. Circumstance for Certificate Re-key: What Certificate Policy is
Section 5.6 of the Certificate Policy referring to? Section 5.6 of
RFC6484 doesn't mention validity intervals.

5.4.1. Types of Events Recorded: Why aren't Key generation, Software
and/or configuration updates to the CA, and Clock adjustments listed?

5.6. Key Changeover: Does mention of validity intervals belong in this
section?


= nits =

Multiple places: Should the RPKI CP be changed to [RFC6484]?

Preface: item 5 lists Acknowledgments three times (twice as
Acknowledgments, once as 12).

1. Introduction: (INRs, see definition in Section 1.7) references a
non-existent section 1.7.

1.1. Overview: Change as described in 2.4 to as described in Section
2.4.

1.4.1. Appropriate Certificate Uses: Change 2.4 to Section 2.4.

2.2. Publication of Certification Information: Should the hyphen in
RPKI-signed objects be changed to a space?

2.3. Time or Frequency of Publication: Change nextScheduledUpdate to
nextUpdate.

3.1.2. Need for Names to be Meaningful: The first two sentences seem
redundant with section 3.1.5.

3.2.6. Criteria for Interoperation: Change e g. to e.g..

4.1.1. Who Can Submit a Certificate Application: Should this
Organization be changed to Name of Organization?

4.2.2. Approval or Rejection of Certificate Applications: Change 3.2.1
to Section 3.2.1.

4.4.2. Publication of the Certificate by the CA: Insert space in
notified.Describe.

4.6.4. Notification of New Certificate Issuance to Subscriber: Change
4.3.2 to Section 4.3.2.

4.7.2. Who May Request Certification of a New Public Key: Change or in
holder or a certificate to of.

4.9.7. CRL Issuance Frequency: Change nextScheduledUpdate to
nextUpdate.

5.7. Compromise and disaster recovery [OMITTED] and 5.8. CA or RA
Termination: These section numbers don't match up with rfc 6484.

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

Re: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01

[David Mandelberg]

In section 8:

   Does RPKI Router protocol implementation support Session ID
   procedures outlined in Section 5.10 of [I-D.ietf-sidr-rpki-rtr]?

I think that should be a reference to section 5.1, not 5.10.

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

[sidr] rpstir-0.4 released

[David Mandelberg]

BBN's RPKI relying party software, rpstir, version 0.4 is now available
at http://sourceforge.net/projects/rpstir/.


Major changes include:

 * Significant improvements to processing and validation of RPKI objects
in conformance with specifications. See below for tests used to improve
conformance to the specifications.

 * Conformance test cases for various specifications. These are also
available at rsync://rpki.bbn.com/conformance/. See
rsync://rpki.bbn.com/conformance/README for more information.

 * Better resistance to denial of service attacks through manifest file
lists (e.g. paths with ../) and an improved algorithm for matching
large lists of ROA prefixes against EE certificate prefixes.


Smaller changes:

 * Performance tuning for rsync.

 * Remove dependency on python-netaddr and improve performance where
python-netaddr used to be used.

 * Fix build and tests on NetBSD.

 * Fix compiling/linking with pthreads on some platforms.

 * More tests can be run under valgrind.

 * Various bug and compiler warning fixes.



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

Re: [sidr] [Technical Errata Reported] RFC6487 (3174)

[David Mandelberg]

On Wed, 2012-04-04 at 09:27 +1000, Geoff Huston wrote:
 I'm tending to a reject. Section 4.8.3 does not precisely apply to CRLs, so 
 to accept this would then require a further errata notice to amend this 
 errata to narrow down the scope of the AIA further.

AKI, not AIA. I just meant that the CRL AKI should have the same format
and meaning as in 4.8.3, i.e. it should use the SHA-1 hash of the
issuer's public key with neither authorityCertIssuer nor
authorityCertSerialNumber fields present. Maybe the errata should be
rejected and resubmitted with text copied and edited from 4.8.3, instead
of referencing 4.8.3?


 Given that the text already says:  The algorithm used in CRLs issued under 
 this profile is specified in [RFC6485]. then I'm not not what futerhe 
 specification is required here.

What part of RFC6485 says anything about CRL AKIs? The closest I can
find is in Section 2:

 NOTE: The exception to the above hashing algorithm is the use
 of SHA-1 [SHS] when Certification Authorities (CAs) generate
 authority and subject key identifiers [RFC6487].

That maybe could be interpreted as saying that CRL AKIs should use
SHA-1, but it doesn't say that authorityCertIssuer and
authorityCertSerialNumber must be absent. It also doesn't explicitly say
what to take the SHA-1 of when generating a CRL AKI.

-- 
David Mandelberg
Wed Apr 4 13:07:37 EDT 2012

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

Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

[David Mandelberg]

   The prefix-to-AS mappings used by the BGP speaker are expected to be
   updated over time.  When a mapping is added or deleted, the
   implementation MUST re-validate any affected prefixes.  An affected
   prefix is any prefix that was matched by a deleted or updated
   mapping, or could be matched by an added mapping.

Shouldn't the two instances of the word 'matched' above be 'covered'
instead since covering mappings also affect validation states?

-- 
David Mandelberg
Wed Mar 21 13:20:52 EDT 2012

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