Re: [sidr] Last Call: draft-ietf-sidr-rfc6490-bis-04.txt (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard
Hi, On Jul 15, 2015, at 6:52 AM, Richard Hansen rhan...@bbn.com wrote: 3. Require line breaks in the Base64 string. For example, change Section 2.1 item #3 from: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]. to: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, a CRLF or LF line break MUST be inserted into the Base64 encoded string every 75 or fewer characters. I prefer option #3. If I understand correctly, OpenSSL's Base64 BIO filter has two modes: no newlines permitted or newlines must be inserted every 79 or fewer characters. I am fine with this option. I agree that it's better to have this explicit. De facto this is what everyone is doing now, and I see no issues with our running code (both trust anchor code producing TALs, and validator code parsing this). Regards Tim Bruijnzeels (RIPE NCC) ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Sandy, On Jul 7, 2015, at 11:41 AM, Stephen Kent k...@bbn.com wrote: - I think the doc should distinguish between transfers of live address space vs. transfers of space that is not currently in use. The former are more complex tan the latter and thus merit a different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. The TAO I-D describes the differences in constraints imposed on the transfer process based on live vs. unused space. Unused is much, much easier and seems to be the most common type of space transferred across RIR boundaries. Thus it seems worth considering the distinction in a discussion of the problem. I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for MA, and for historical resources. Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space. MA are likely to be live and historical could be live, I suppose. It's interesting that they make these distinctions, presumably for policy purposes. i don't find anything in their policy manual that says transfers are only for unused space. I did not suggested that. What I said was that it seems likely that the growing number of address space transfers will be for unused space, IF the reason for the transfer is a sale of assets. (This seems to be the rationale cited for the growth in v4 address space transfers.) And, I noted that it seems attractive to engineer a solution to for unused space transfers IF the solution is simpler than for live space transfers (it is), and IF unused space transfers are the common case. Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer
Let me understand the semantics of the RLP field better. I am assuming
that it indicates that a leak happened somewhere in the path,
RLP field does not indicate (or encode) that a *leak happened*.
It merely facilitates a receiving router to detect if an update
from a sending router (an adjacent AS) is a route leak.
Example 1: Route for prefix P propagates as follows:
P---AS A ---{ RLP(AB) = 01 }--- AS B (cust. of A) ---{ RLP(BC) = 01, RLP(AB)
= 01 }--- AS C (cust. of B)
Sequentially, B is a customer of A, and C is a customer of B.
The expression in wiggly brackets {} shows the RLP values in the prefix update.
A transitive RLP field is added in the update for each hop in the path.
Each AS sets an RLP value for its hop to the next AS for the route it forwards
for prefix P.
RLP = 01 indicates that the update SHOULD NOT be sent 'up' to a provider (or
'laterally' to a peer), but it is allowed to forward the update to a customer.
So no one in this Example 1 detects a route leak. There is no route leak.
Example 2:
P---AS A ---{ RLP(AB) =01 } --- AS B (cust. of A) --- { RLP(AB) =01, RLP(BC)
=00) } --- AS C (provider of B)
B (in the middle) has two providers A and C.
B learned a route from A and is leaking the route to C, and C detects it.
C looks at RLP(AB) = 01, and therefore it knows that B's update is a leak.
So C marks B's update as a route leak.
not necessarily at the adjacent AS (your customer or your peer).
As in the examples above, the receiver is only detecting if the update from
its adjacent router is a route leak. It does so by looking
at NOT the RLP field value set by the adjacent router
but the RLP field values set by the ASes that preceded it.
If this is indeed so, the only case I can think of when an RLP-marked update
is not
a leak, is when it came from the upstream.
May be this question goes away in light of the proper understanding
of RLP field values provided above.
It is true that an upstream provider cannot leak any prefix route to its
customer by definition. Any prefix routes that the upstream has accepted
(after applying route leak detection/mitigation etc.), the upstream usually
send all
those routes to its customer (except those learned from that customer).
So in general, a customer need not try to detect route leak from its upstream
provider
(keep in mind that we are talking about the relationships on per prefix basis).
(Please ignore what I said in my previous reply to you about detecting route
leaks from a provider; the last paragraph.)
We have not used the term RLP-marked anywhere in the draft.
So I don't know what exactly you mean by it.
But hopefully the above explanations clarify things for you.
When we say an update is 'marked', it simply means that it was detected
to be a route leak (as it was received from a neighbor AS).
And if we follow the same logic an RLP-marked update from the upstream
can still be a leak (and not just downstream announcements), but I think
it would be difficult to distinguish between the two.
If my considerations are correct, there are only two cases -
upstreams/transit providers, for which RLP doesn't matter, and others
(customers and peers) where an RLP indicates a leak and has to be dealt
accordingly.
Yes, I agree that detecting route leaks from customers/peers matters.
Detecting route leaks from upstreams/transit providers does not really matter
(as explained above).
Related to the latter - what would be in your opinion a reason to accept
a leaked route? Is it just for reachability (i.e. only one route to the
destination), or are there legitimate cases for route leaks?
In this discussion and the draft, we have not called anything a
legitimate route leak. But some customer ASes could make mistakes.
For example, if X is single-homed stub customer of Y and Y is a customer of Z,
and if X sets RLP = 01 by mistake in its prefix update to Y, then Z detects and
marks
the prefix route from Y as a route leak.
Z will not have any alternate path for that prefix because X is single-homed
stub.
In this case, Z may accept the update for reachability even though it was
detected to be route leak. Again, we don't specify this.
We only specify the detection method, not the mitigation policy.
Thank you.
Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt
On 2015-07-03 06:39, Sandra Murphy wrote: Speaking as regular ol' member On May 21, 2015, at 6:38 PM, Richard Hansen rhan...@bbn.com wrote: On 2015-05-21 17:08, Sandra Murphy wrote: On May 20, 2015, at 4:03 PM, Richard Hansen rhan...@bbn.com wrote: * section 8 is incorrect -- sha256WithRSAEncryption does not violate the CMS RFCs (implementations just choose to use rsaEncryption instead, which has the same meaning in this context) [...] Perhaps you are concerned mostly about the terms being used? But the rfc6485bis document does not say violate and I believe that what it says agrees with the message above. If you don't think so, you should say why. This draft's Section 8 says: [...]A closer reading of [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field must support use of the rsaEncryption OID for full conformance with the CMS specifications, and the normative references in [RFC6485] inherited this requirement. The phrase the CMS SignerInfo field must support use of the rsaEncryption OID doesn't make much sense to me -- how can an OID field not support an OID? I'm not 100% sure what is meant here, but the next paragraph provides a hint: [...] By conforming to the CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects are less likely to be rejected as non-conformant with the CMS standards. To me, this sentence and the one above are claiming that the CMS RFCs say that the SignerInfo signatureAlgorithm field MUST contain rsaEncryption, and that we are non-conformant (violating the spec) by using sha256WithRSAEncryption. Neither is true. You and I disagree here. To be clear: our disagreement is whether the description of the motivation for the change to RFC6485 is ambiguous or not. I feel that Section 8 is incorrect, not just unclear. (If I'm interpreting it in a way that is not intended by the authors, and I don't think I am, then this disagreement *is* just about clarity, not correctness.) Personally, I do not consider that an important matter. The description of the motivation does not change the specification, it does not change implementation, and it does not confuse implementors about implementation. I agree that Section 8 as worded does not impact implementations of *this* standard. My concern is that the current wording adds to the existing confusion surrounding the CMS signed object spec, and that people trying to understand the CMS standard will see this section and reach an incorrect conclusion. To recap: RFC6485 chose to mandate an algorithm id. That choice is compliant with the CMS RFCs. The CMS RFCs make a choice of a mandatory to implement algorithm ID. RFC6485's choice is not the CMS mandatory to implement choice. Unfortunately, common CMS implementations chose to support only the CMS mandatory to implement algorithm ID. So common CMS implementations can not be compliant with RFC6485. By aligning our choice of mandatory algorithm ID with the mandatory algorithm in the CMS RFCs, we make it possible for common CMS implementations to be compliant with RFC6485. By aligning our choice of mandatory algorithm ID with the mandatory algorithm in the CMS RFCs, we eliminate the problem that a compliant RPKI signed object would be rejected by the common CMS implementations. Yes, I agree with this recap. wrt: [...] By conforming to the CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects are less likely to be rejected as non-conformant with the CMS standards. Perhaps you are reading too much into the use of conforming to? There is a chance I am interpreting that sentence in a way not intended by the authors. If I am, then something should be done to reduce the difficulty of interpreting the sentence correctly. If I am not, then something should be done to correct the sentence. Either way, something should be done. Perhaps saying aligning with would make it more clear to you? That's an improvement, but still not sufficient. I sent a suggested rewrite of Section 8 to the authors on 2015-05-20 with no response; here's a more minimal rewrite of just that sentence: [...] By requiring RPKI CMS signed objects to use an OID that is widely supported by existing libraries, implementations are less likely to reject valid RPKI CMS signed objects due to incomplete algorithm support. I do not know what current CMS implementations would do if they were presented with a RFC6485 compliant RPKI signed object. RPSTIR currently accepts either OID. Before this OID issue was raised, RPSTIR only accepted CMS signed objects that used sha256WithRSAEncryption. CMS signed objects that used rsaEncryption were rejected due to non-conformance with RFC6485. They may
Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer
Andrei,
Thank you for reading the draft and offering comments -- certainly very helpful
towards refining the proposal as well adding greater clarity in the document.
It seems to me that sections 3.2.1. and 3.2.2. propose the same
algorithm (modulo the BGP neighbor is a customer or a peer).
Your observation is correct. It has to do with the semantics of RLP bits.
For now, we have RLP = 00 (default; nothing said) and RLP = 01 ('do not
propagate up').
'Do not propagate up' certainly means that the update should not subsequently
propagate from a customer to its provider.
However, a receiver can (at its own discretion) interpret RLP = 01 more
strictly
to mean 'do not propagate to provider or peer'.
That is because if an ISP is not supposed to forward an update with RLP = 01
'up' to a provider, then normally it should not forward it 'laterally' to a
peer either.
So we have separated the receiver detection procedures for
(a) when the update comes from a *customer* (section 3.2.1), and
vs. (b) when it comes from a *peer* (section 3.2.2).
The difference is the stricter interpretation (in Section 3.2.2) of RLP = 01.
Initially the attempt is to see if we can keep the RLP semantics simple,
and still accomplish the detection objectives w.r.t. customer/peer.
These two section can be merged into one if, for example,
RLP = 01 is specified to denote 'do not propagate to provider or peer'.
The difference in the possible actions (3.3.) is not clear to me either.
When an update is detected and 'marked' as 'route leak' (based on section 3.2.1
or 3.2.2 detection),
then the same/similar method(s) of mitigation can be applied (in the two
cases).
The draft should not specify a mitigation method because that is left to
operator policy.
So we describe only an *example* policy: Suspend the prefer customer policy;
i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'
update from a provider or peer. Some similar policy can be applied for a peer.
Let the operator decide the actual policy to be used in each case.
Finally, what is the proposed action when an RLP-marked update is
received from an upstream?
Good point. The draft currently does not discuss this. If the customer
is single-homed and does not have any alternate path for the prefix,
then it would install the route learned from its sole provider even if it is
'marked'.
If the customer is multi-homed, it should prefer an 'unmarked' update from
one provider over a 'marked' update from another provider. Etc.
Again these actions/methods are left to operator policy.
However, in the next revision, we will include a subsection to outline this.
Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer
Thank you for your response, Sriram.
Let me understand the semantics of the RLP field better. I am assuming
that it indicates that a leak happened somewhere in the path, not
necessarily at the adjacent AS (your customer or your peer). If this is
indeed so, the only case I can think of when an RLP-marked update is not
a leak, is when it came from the upstream.
And if we follow the same logic an RLP-marked update from the upstream
can still be a leak (and not just downstream announcements), but I think
it would be difficult to distinguish between the two.
If my considerations are correct, there are only two cases -
upstreams/transit providers, for which RLP doesn't matter, and others
(customers and peers) where an RLP indicates a leak and has to be dealt
accordingly.
Related to the latter - what would be in your opinion a reason to accept
a leaked route? Is it just for reachability (i.e. only one route to the
destination), or are there legitimate cases for route leaks?
Thanks,
Andrei
Sriram, Kotikalapudi wrote on 15/07/15 15:03:
Andrei,
Thank you for reading the draft and offering comments -- certainly very
helpful
towards refining the proposal as well adding greater clarity in the document.
It seems to me that sections 3.2.1. and 3.2.2. propose the same
algorithm (modulo the BGP neighbor is a customer or a peer).
Your observation is correct. It has to do with the semantics of RLP bits.
For now, we have RLP = 00 (default; nothing said) and RLP = 01 ('do not
propagate up').
'Do not propagate up' certainly means that the update should not subsequently
propagate from a customer to its provider.
However, a receiver can (at its own discretion) interpret RLP = 01 more
strictly
to mean 'do not propagate to provider or peer'.
That is because if an ISP is not supposed to forward an update with RLP = 01
'up' to a provider, then normally it should not forward it 'laterally' to a
peer either.
So we have separated the receiver detection procedures for
(a) when the update comes from a *customer* (section 3.2.1), and
vs. (b) when it comes from a *peer* (section 3.2.2).
The difference is the stricter interpretation (in Section 3.2.2) of RLP = 01.
Initially the attempt is to see if we can keep the RLP semantics simple,
and still accomplish the detection objectives w.r.t. customer/peer.
These two section can be merged into one if, for example,
RLP = 01 is specified to denote 'do not propagate to provider or peer'.
The difference in the possible actions (3.3.) is not clear to me either.
When an update is detected and 'marked' as 'route leak' (based on section
3.2.1 or 3.2.2 detection),
then the same/similar method(s) of mitigation can be applied (in the two
cases).
The draft should not specify a mitigation method because that is left to
operator policy.
So we describe only an *example* policy: Suspend the prefer customer policy;
i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'
update from a provider or peer. Some similar policy can be applied for a
peer.
Let the operator decide the actual policy to be used in each case.
Finally, what is the proposed action when an RLP-marked update is
received from an upstream?
Good point. The draft currently does not discuss this. If the customer
is single-homed and does not have any alternate path for the prefix,
then it would install the route learned from its sole provider even if it is
'marked'.
If the customer is multi-homed, it should prefer an 'unmarked' update from
one provider over a 'marked' update from another provider. Etc.
Again these actions/methods are left to operator policy.
However, in the next revision, we will include a subsection to outline this.
Sriram
signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
