Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Thomas King]

I propose to add the following to section “Operational Recommendations”:

3.3.  Information about Validity of a BGP Prefix Origin Not Available at
  a Route-Server

   In case information about the validity of a BGP prefix origin is not
   available at the route-server (e.g., error in the ROA cache, CPU
   overload) the route-server MUST NOT add the BGP Prefix Origin
   Validation State Extended Community to the route.



Best regards,
Thomas




On 26/04/2016, 14:33, "Thomas King"  wrote:

>I would like to come back to a solution that was discussed already: If the 
>route-server is not able to perform the origin prefix validation the BGP 
>community is not added to the BGP update. The BGP community is only added if 
>the origin prefix validation could be executed.
>
>This solution allows a clear signalling. This would also be compatible with 
>the current ietf-sidr-origin-validation-signaling document and could be easily 
>stated in draft-kklf-sidr-route-server-rpki-light.
>
>Best regards,
>Thomas
>
>
>
>
>On 26/04/2016, 13:32, "Matthias Waehlisch"  wrote:
>
>>There was a quite similar discussion in 2013, for the thread see
>>
>>https://mailarchive.ietf.org/arch/msg/sidr/zvSP_-iiEfu_acYInK5lOMnys5U
>>
>>As far as I remember w/o a final conclusion (or the conclusion was 
>>leave it as is).
>>
>>
>>Cheers
>>  matthias
>>
>>On Tue, 26 Apr 2016, Thomas King wrote:
>>
>>> Hi all,
>>> 
>>> Following up on the discussion we had during the last IETF meeting I would 
>>> like to discuss with you how we proceed with the “Did not perform 
>>> validation” value. I think this value is very important and should be added 
>>> to ietf-sidr-origin-validation-signaling.
>>> 
>>> Best regards,
>>> Thomas
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>>
>>
>>-- 
>>Dr. Matthias Waehlisch
>>.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
>>.  Takustr. 9, D-14195 Berlin, Germany
>>.. mailto:m.waehli...@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl
>>:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Randy Bush]

> I would like to come back to a solution that was discussed already: If
> the route-server is not able to perform the origin prefix validation
> the BGP community is not added to the BGP update. The BGP community is
> only added if the origin prefix validation could be executed.
> 
> This solution allows a clear signalling. This would also be compatible
> with the current ietf-sidr-origin-validation-signaling document and
> could be easily stated in draft-kklf-sidr-route-server-rpki-light.

you're welcome

randy

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

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Thomas King]

I would like to come back to a solution that was discussed already: If the 
route-server is not able to perform the origin prefix validation the BGP 
community is not added to the BGP update. The BGP community is only added if 
the origin prefix validation could be executed.

This solution allows a clear signalling. This would also be compatible with the 
current ietf-sidr-origin-validation-signaling document and could be easily 
stated in draft-kklf-sidr-route-server-rpki-light.

Best regards,
Thomas




On 26/04/2016, 13:32, "Matthias Waehlisch"  wrote:

>There was a quite similar discussion in 2013, for the thread see
>
>https://mailarchive.ietf.org/arch/msg/sidr/zvSP_-iiEfu_acYInK5lOMnys5U
>
>As far as I remember w/o a final conclusion (or the conclusion was 
>leave it as is).
>
>
>Cheers
>  matthias
>
>On Tue, 26 Apr 2016, Thomas King wrote:
>
>> Hi all,
>> 
>> Following up on the discussion we had during the last IETF meeting I would 
>> like to discuss with you how we proceed with the “Did not perform 
>> validation” value. I think this value is very important and should be added 
>> to ietf-sidr-origin-validation-signaling.
>> 
>> Best regards,
>> Thomas
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>
>
>-- 
>Dr. Matthias Waehlisch
>.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
>.  Takustr. 9, D-14195 Berlin, Germany
>.. mailto:m.waehli...@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl
>:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Matthias Waehlisch]

There was a quite similar discussion in 2013, for the thread see

https://mailarchive.ietf.org/arch/msg/sidr/zvSP_-iiEfu_acYInK5lOMnys5U

As far as I remember w/o a final conclusion (or the conclusion was 
leave it as is).


Cheers
  matthias

On Tue, 26 Apr 2016, Thomas King wrote:

> Hi all,
> 
> Following up on the discussion we had during the last IETF meeting I would 
> like to discuss with you how we proceed with the “Did not perform validation” 
> value. I think this value is very important and should be added to 
> ietf-sidr-origin-validation-signaling.
> 
> Best regards,
> Thomas
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> 


-- 
Dr. Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:m.waehli...@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Thomas King]

Hi all,

Following up on the discussion we had during the last IETF meeting I would like 
to discuss with you how we proceed with the “Did not perform validation” value. 
I think this value is very important and should be added to 
ietf-sidr-origin-validation-signaling.

Best regards,
Thomas
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Thomas King]

Hi Sriram,

thanks for your feedback. I comment inline.

> On 28 Mar 2016, at 22:14, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> I read the draft. A few comments:
> 
> 1. RPKI validation refers to checking cryptographic integrity of the RPKI 
> objects such as certs, ROAs, etc.
> What you intend to signal from RS to peers is prefix-origin validation 
> results (RFC 6811).
> s/RPKI validation results/ prefix-origin validation results/g

Fixed.

> 
> 2. "Route-servers providing RPKI-based route
>   origin validation set the validation state according to the RPKI
>   validation result (see [I-D.ietf-sidr-rpki-validation-reconsidered])."  (in 
> Section 2)
> 
> The reference cited here is incorrect. It should be RFC 6811.
> RFC 6811 defines the prefix-origin validation states and also provides the 
> validation algorithm.

Fixed.

> 3. How do you signal that the RS did not perform validation on an update (for 
> whatever reason).
> Is that implicitly conveyed when the "Prefix Origin Validation State Extended 
> Community"
> is absent in the update forwarded to peers? May be it needs to be said in the 
> draft.
> For instance, 'Not Found' should not be used as default value in the extended 
> community.
> 'Did not perform validation' should not be equated to 'Not Found’.

I see your point.
I do not want to add another state as ietf-sidr-origin-validation-signaling 
defines only the ones used in this draft. I would like to be as close as 
possible to ietf-sidr-origin-validation-signaling as this draft just adds 
another use-case (route servers) to the concept.
If validation could not be performed by the route server no community should be 
set. The receiving peer should treat the update as if no prefix origin 
validation information was provided by the route server for this prefix ever. 
If this is okay with you I will add section covering this topic in the 
Recommendation section.

Best regards,
Thomas






smime.p7s
Description: S/MIME cryptographic signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

[Sriram, Kotikalapudi (Fed)]

I read the draft. A few comments:

1. RPKI validation refers to checking cryptographic integrity of the RPKI 
objects such as certs, ROAs, etc.
What you intend to signal from RS to peers is prefix-origin validation results 
(RFC 6811).
s/RPKI validation results/ prefix-origin validation results/g

2. "Route-servers providing RPKI-based route
   origin validation set the validation state according to the RPKI
   validation result (see [I-D.ietf-sidr-rpki-validation-reconsidered])."  (in 
Section 2)

The reference cited here is incorrect. It should be RFC 6811.
RFC 6811 defines the prefix-origin validation states and also provides the 
validation algorithm.

3. How do you signal that the RS did not perform validation on an update (for 
whatever reason).
Is that implicitly conveyed when the "Prefix Origin Validation State Extended 
Community"
is absent in the update forwarded to peers? May be it needs to be said in the 
draft.
For instance, 'Not Found' should not be used as default value in the extended 
community.
'Did not perform validation' should not be equated to 'Not Found'.

Sriram




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