Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Matthias Waehlisch]

Thanks! No further comments from my side. Looing forward to publication.


Cheers
  matthias

On Fri, 24 Jun 2016, Randy Bush wrote:

> >   I read v09. No objections only minor comments:
> 
> i hacked in many of these changes, though i think most did not really
> change anything other than an alternate way of saying the same thing.
> but i just do not want to see this go on an on interminably.  and at
> least you reviewed it.  thanks!
> 
> randy
> 
> > 
> > line 102: BGPsec need*s* *to* be spoken only
> > 
> > line 104: s/by small edge routers/by resource constrained edge routers/
> > 
> > line 119: *see* [RFC4271]
> > 
> > line 159: s//etc./
> > 
> > lines 200-206 seem redudant to lines 208-213
> > 
> > line 202 s/smallish/resource constrained/
> > 
> > line 215: I don't know where the 84% comes from, I suppose it's just a 
> > more or less arbitrary illustration of "vast majority". I would remove 
> > the number.
> > 
> > line 234: I would be more explicit: "How this is used in routing is up 
> > to the operator's local policy, similar to origin validation [RFC6811]."
> > 
> > lines 243-250: This paragraph confused me. What about:
> > 
> > Operators should be aware that controlling Invalid announcements by 
> > local preference might be delusive. Local preference affects only routes 
> > to the same set of destinations. Consider having a Valid announcement 
> > from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
> > 10.0.66.0/24 from neighbor I. If the local policy on a router is 
> > configured to accept Invalid announcements, then both routes will be 
> > installed, no matter of the value of local preference.
> > 
> > (Btw, I suppose that routes to .666 will be discarded anyway ;)
> > 
> > line 252: It sounds that only edge routers are allowed to speak BGPsec. 
> > I would weaken and say "Validation of signed paths is usually deployed 
> > at the eBGP edge."
> > 
> > line 292: s/BGPSEC_Path/BGPsec_Path/
> > 
> > lines 288-295:  The paragraph seems to mix transparent operation and the 
> > question of validation. What about:
> > 
> > A route server is usually 'transparent'. To operate transparently in an 
> > environment in which the route server connects BGPsec-enabled peers, the 
> > route server needs to run BGPsec as well. This implies that the route 
> > server creates signatures per client including its own AS in the 
> > BGPsec_Path and the target ASes. However, increasing the AS hop count 
> > reduces the likelihood of best path selection. See 2.2.2 of 
> > [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
> > server uses pCount of zero to not increase the effective AS hop count.
> > 
> > Furthermore, a BGPsec-aware route server needs to validate the incoming 
> > BGPsec_Path but should not drop invalids. In case the client speaks 
> > BGPsec the route server should just forward updates to clients which 
> > then validate . In case the client does not speak BGPsec, the route 
> > server reconstructs the AS_PATH and may signal the validation outcome 
> > using communities.
> > 
> > line 300: s/Routers should default to this knob disallowing pCount 
> > 0./Routers should disallow pCount 0 by default./
> > 
> > line 346: I would rephrase: "Operators should deploy servers that 
> > provide time service, such as [RFC5905], to client routers."
> 

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

>   I read v09. No objections only minor comments:

i hacked in many of these changes, though i think most did not really
change anything other than an alternate way of saying the same thing.
but i just do not want to see this go on an on interminably.  and at
least you reviewed it.  thanks!

randy

> 
> line 102: BGPsec need*s* *to* be spoken only
> 
> line 104: s/by small edge routers/by resource constrained edge routers/
> 
> line 119: *see* [RFC4271]
> 
> line 159: s//etc./
> 
> lines 200-206 seem redudant to lines 208-213
> 
> line 202 s/smallish/resource constrained/
> 
> line 215: I don't know where the 84% comes from, I suppose it's just a 
> more or less arbitrary illustration of "vast majority". I would remove 
> the number.
> 
> line 234: I would be more explicit: "How this is used in routing is up 
> to the operator's local policy, similar to origin validation [RFC6811]."
> 
> lines 243-250: This paragraph confused me. What about:
> 
> Operators should be aware that controlling Invalid announcements by 
> local preference might be delusive. Local preference affects only routes 
> to the same set of destinations. Consider having a Valid announcement 
> from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
> 10.0.66.0/24 from neighbor I. If the local policy on a router is 
> configured to accept Invalid announcements, then both routes will be 
> installed, no matter of the value of local preference.
> 
> (Btw, I suppose that routes to .666 will be discarded anyway ;)
> 
> line 252: It sounds that only edge routers are allowed to speak BGPsec. 
> I would weaken and say "Validation of signed paths is usually deployed 
> at the eBGP edge."
> 
> line 292: s/BGPSEC_Path/BGPsec_Path/
> 
> lines 288-295:  The paragraph seems to mix transparent operation and the 
> question of validation. What about:
> 
> A route server is usually 'transparent'. To operate transparently in an 
> environment in which the route server connects BGPsec-enabled peers, the 
> route server needs to run BGPsec as well. This implies that the route 
> server creates signatures per client including its own AS in the 
> BGPsec_Path and the target ASes. However, increasing the AS hop count 
> reduces the likelihood of best path selection. See 2.2.2 of 
> [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
> server uses pCount of zero to not increase the effective AS hop count.
> 
> Furthermore, a BGPsec-aware route server needs to validate the incoming 
> BGPsec_Path but should not drop invalids. In case the client speaks 
> BGPsec the route server should just forward updates to clients which 
> then validate . In case the client does not speak BGPsec, the route 
> server reconstructs the AS_PATH and may signal the validation outcome 
> using communities.
> 
> line 300: s/Routers should default to this knob disallowing pCount 0./Routers 
> should disallow pCount 0 by default./
> 
> line 346: I would rephrase: "Operators should deploy servers that 
> provide time service, such as [RFC5905], to client routers."

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

matthias,

> one more: Can you please replace "Invalid" by "Not Valid", because 
> this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.

done.

randy

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Matthias Waehlisch]

Hi Randy,

  one more: Can you please replace "Invalid" by "Not Valid", because 
this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.


Thanks
  matthias

On Thu, 16 Jun 2016, Matthias Waehlisch wrote:

> Hi,
> 
>   I read v09. No objections only minor comments:
> 
> line 102: BGPsec need*s* *to* be spoken only
> 
> line 104: s/by small edge routers/by resource constrained edge routers/
> 
> line 119: *see* [RFC4271]
> 
> line 159: s//etc./
> 
> lines 200-206 seem redudant to lines 208-213
> 
> line 202 s/smallish/resource constrained/
> 
> line 215: I don't know where the 84% comes from, I suppose it's just a 
> more or less arbitrary illustration of "vast majority". I would remove 
> the number.
> 
> line 234: I would be more explicit: "How this is used in routing is up 
> to the operator's local policy, similar to origin validation [RFC6811]."
> 
> lines 243-250: This paragraph confused me. What about:
> 
> Operators should be aware that controlling Invalid announcements by 
> local preference might be delusive. Local preference affects only routes 
> to the same set of destinations. Consider having a Valid announcement 
> from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
> 10.0.66.0/24 from neighbor I. If the local policy on a router is 
> configured to accept Invalid announcements, then both routes will be 
> installed, no matter of the value of local preference.
> 
> (Btw, I suppose that routes to .666 will be discarded anyway ;)
> 
> line 252: It sounds that only edge routers are allowed to speak BGPsec. 
> I would weaken and say "Validation of signed paths is usually deployed 
> at the eBGP edge."
> 
> line 292: s/BGPSEC_Path/BGPsec_Path/
> 
> lines 288-295:  The paragraph seems to mix transparent operation and the 
> question of validation. What about:
> 
> A route server is usually 'transparent'. To operate transparently in an 
> environment in which the route server connects BGPsec-enabled peers, the 
> route server needs to run BGPsec as well. This implies that the route 
> server creates signatures per client including its own AS in the 
> BGPsec_Path and the target ASes. However, increasing the AS hop count 
> reduces the likelihood of best path selection. See 2.2.2 of 
> [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
> server uses pCount of zero to not increase the effective AS hop count.
> 
> Furthermore, a BGPsec-aware route server needs to validate the incoming 
> BGPsec_Path but should not drop invalids. In case the client speaks 
> BGPsec the route server should just forward updates to clients which 
> then validate . In case the client does not speak BGPsec, the route 
> server reconstructs the AS_PATH and may signal the validation outcome 
> using communities.
> 
> line 300: s/Routers should default to this knob disallowing pCount 0./Routers 
> should disallow pCount 0 by default./
> 
> line 346: I would rephrase: "Operators should deploy servers that 
> provide time service, such as [RFC5905], to client routers."
> 
> 
> 
> Cheers
>   matthias
> 
> On Wed, 15 Jun 2016, Sandra Murphy wrote:
> 
> > It is a short document.  The sentences are not complicated.  It reads 
> > quickly.
> > 
> > There’s been little/no wg comment on this, certainly no controversy, over 
> > the lifetime of the draft.
> > 
> > But still.
> > 
> > Please.  Pretty please.  Pretty please with sugar on top.  Pretty please 
> > with a cherry on top.
> > 
> > Could we get some feedback that this document is ready for publication?
> > 
> > —Sandy, speaking as one of the wg co-chairs
> > 
> > 
> > On Jun 8, 2016, at 10:19 PM, Sandra Murphy  wrote:
> > 
> > > No responses at all.
> > > 
> > > Come on folks.  It’s a short document, like Chris says.
> > > 
> > > You should be able to read and comment without much trouble.
> > > 
> > > —Sandy, speaking as one of the wg co-chairs
> > > 
> > > On Jun 1, 2016, at 2:52 PM, Chris Morrow  wrote:
> > > 
> > >> 
> > >> Howdy WG folks,
> > >> Please take this note as the start of the 2wk WGLC period for:
> > >> 
> > >> 
> > >> Abstract:
> > >> "Deployment of the BGPsec architecture and protocols has many
> > >>  operational considerations.  This document attempts to collect and
> > >>  present the most critical and universal.  It is expected to evolve as
> > >>  BGPsec is formalized and initially deployed."
> > >> 
> > >> This is a relatively short document, 8 pages, full of wonder and
> > >> excitement! I hope that the wg members have read it (it's been through
> > >> 8+ revisions) and that they will re-read it quickly, provide comments
> > >> as appropriate and ideas on preparedness for publication or not.
> > >> 
> > >> 
> > >> Thanks for you time and attention to this matter,
> > >> 
> > >> -Chris
> > >> co-chair-persona
> > >> 
> > >> ___
> > >> sidr mailing list
> 

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Matthias Waehlisch]

Hi,

  I read v09. No objections only minor comments:

line 102: BGPsec need*s* *to* be spoken only

line 104: s/by small edge routers/by resource constrained edge routers/

line 119: *see* [RFC4271]

line 159: s//etc./

lines 200-206 seem redudant to lines 208-213

line 202 s/smallish/resource constrained/

line 215: I don't know where the 84% comes from, I suppose it's just a 
more or less arbitrary illustration of "vast majority". I would remove 
the number.

line 234: I would be more explicit: "How this is used in routing is up 
to the operator's local policy, similar to origin validation [RFC6811]."

lines 243-250: This paragraph confused me. What about:

Operators should be aware that controlling Invalid announcements by 
local preference might be delusive. Local preference affects only routes 
to the same set of destinations. Consider having a Valid announcement 
from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
10.0.66.0/24 from neighbor I. If the local policy on a router is 
configured to accept Invalid announcements, then both routes will be 
installed, no matter of the value of local preference.

(Btw, I suppose that routes to .666 will be discarded anyway ;)

line 252: It sounds that only edge routers are allowed to speak BGPsec. 
I would weaken and say "Validation of signed paths is usually deployed 
at the eBGP edge."

line 292: s/BGPSEC_Path/BGPsec_Path/

lines 288-295:  The paragraph seems to mix transparent operation and the 
question of validation. What about:

A route server is usually 'transparent'. To operate transparently in an 
environment in which the route server connects BGPsec-enabled peers, the 
route server needs to run BGPsec as well. This implies that the route 
server creates signatures per client including its own AS in the 
BGPsec_Path and the target ASes. However, increasing the AS hop count 
reduces the likelihood of best path selection. See 2.2.2 of 
[I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
server uses pCount of zero to not increase the effective AS hop count.

Furthermore, a BGPsec-aware route server needs to validate the incoming 
BGPsec_Path but should not drop invalids. In case the client speaks 
BGPsec the route server should just forward updates to clients which 
then validate . In case the client does not speak BGPsec, the route 
server reconstructs the AS_PATH and may signal the validation outcome 
using communities.

line 300: s/Routers should default to this knob disallowing pCount 0./Routers 
should disallow pCount 0 by default./

line 346: I would rephrase: "Operators should deploy servers that 
provide time service, such as [RFC5905], to client routers."



Cheers
  matthias

On Wed, 15 Jun 2016, Sandra Murphy wrote:

> It is a short document.  The sentences are not complicated.  It reads quickly.
> 
> There’s been little/no wg comment on this, certainly no controversy, over the 
> lifetime of the draft.
> 
> But still.
> 
> Please.  Pretty please.  Pretty please with sugar on top.  Pretty please with 
> a cherry on top.
> 
> Could we get some feedback that this document is ready for publication?
> 
> —Sandy, speaking as one of the wg co-chairs
> 
> 
> On Jun 8, 2016, at 10:19 PM, Sandra Murphy  wrote:
> 
> > No responses at all.
> > 
> > Come on folks.  It’s a short document, like Chris says.
> > 
> > You should be able to read and comment without much trouble.
> > 
> > —Sandy, speaking as one of the wg co-chairs
> > 
> > On Jun 1, 2016, at 2:52 PM, Chris Morrow  wrote:
> > 
> >> 
> >> Howdy WG folks,
> >> Please take this note as the start of the 2wk WGLC period for:
> >> 
> >> 
> >> Abstract:
> >> "Deployment of the BGPsec architecture and protocols has many
> >>  operational considerations.  This document attempts to collect and
> >>  present the most critical and universal.  It is expected to evolve as
> >>  BGPsec is formalized and initially deployed."
> >> 
> >> This is a relatively short document, 8 pages, full of wonder and
> >> excitement! I hope that the wg members have read it (it's been through
> >> 8+ revisions) and that they will re-read it quickly, provide comments
> >> as appropriate and ideas on preparedness for publication or not.
> >> 
> >> 
> >> Thanks for you time and attention to this matter,
> >> 
> >> -Chris
> >> co-chair-persona
> >> 
> >> ___
> >> 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] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Randy Bush]

> Line 94: There’s a typo: “twp” instead of “two”
> Line 202: Grammatical error: “it’s” instead of “its”
> Line 317: Typo: “see see” instead of “see”



>>  BGPsec protocol capability negotiation provides for a speaker signing
>>the data it sends without being able to accept signed data.  Thus a
>>smallish edge router may hold only its own signing key(s), sign it's
>>announcements, but not receive signed announcements and therefore not
>>need to deal with the majority of the RPKI.  Thus such routers CPU,
>>RAM, and crypto needs are trivial and additional hardware should not
>>be needed.
> 
> “Operators might be utilising hardware with limited resources. In such
> cases, BGPsec protocol capability negotiation allows for a resource
> constrained edge router to just hold its own signing key(s) and sign
> its announcements, but not receive signed announcements. Therefore,
> the router would not have to deal with the majority of the RPKI,
> potentially saving the need for additional hardware."

eenie meenie.  but if it makes you happy, i'll use yours.

randy

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Sean Turner]

I read it and think it answer the mail.  Ship it.

spt

> On Jun 15, 2016, at 08:35, Sandra Murphy  wrote:
> 
> It is a short document.  The sentences are not complicated.  It reads quickly.
> 
> There’s been little/no wg comment on this, certainly no controversy, over the 
> lifetime of the draft.
> 
> But still.
> 
> Please.  Pretty please.  Pretty please with sugar on top.  Pretty please with 
> a cherry on top.
> 
> Could we get some feedback that this document is ready for publication?
> 
> —Sandy, speaking as one of the wg co-chairs
> 
> 
> On Jun 8, 2016, at 10:19 PM, Sandra Murphy  wrote:
> 
>> No responses at all.
>> 
>> Come on folks.  It’s a short document, like Chris says.
>> 
>> You should be able to read and comment without much trouble.
>> 
>> —Sandy, speaking as one of the wg co-chairs
>> 
>> On Jun 1, 2016, at 2:52 PM, Chris Morrow  wrote:
>> 
>>> 
>>> Howdy WG folks,
>>> Please take this note as the start of the 2wk WGLC period for:
>>> 
>>> 
>>> Abstract:
>>> "Deployment of the BGPsec architecture and protocols has many
>>> operational considerations.  This document attempts to collect and
>>> present the most critical and universal.  It is expected to evolve as
>>> BGPsec is formalized and initially deployed."
>>> 
>>> This is a relatively short document, 8 pages, full of wonder and
>>> excitement! I hope that the wg members have read it (it's been through
>>> 8+ revisions) and that they will re-read it quickly, provide comments
>>> as appropriate and ideas on preparedness for publication or not.
>>> 
>>> 
>>> Thanks for you time and attention to this matter,
>>> 
>>> -Chris
>>> co-chair-persona
>>> 
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Sandra Murphy]

No responses at all.

Come on folks.  It’s a short document, like Chris says.

You should be able to read and comment without much trouble.

—Sandy, speaking as one of the wg co-chairs

On Jun 1, 2016, at 2:52 PM, Chris Morrow  wrote:

> 
> Howdy WG folks,
> Please take this note as the start of the 2wk WGLC period for:
>  
> 
> Abstract:
>  "Deployment of the BGPsec architecture and protocols has many
>   operational considerations.  This document attempts to collect and
>   present the most critical and universal.  It is expected to evolve as
>   BGPsec is formalized and initially deployed."
> 
> This is a relatively short document, 8 pages, full of wonder and
> excitement! I hope that the wg members have read it (it's been through
> 8+ revisions) and that they will re-read it quickly, provide comments
> as appropriate and ideas on preparedness for publication or not.
> 
> 
> Thanks for you time and attention to this matter,
> 
> -Chris
> co-chair-persona
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Chris Morrow]

Howdy WG folks,
Please take this note as the start of the 2wk WGLC period for:
  

Abstract:
  "Deployment of the BGPsec architecture and protocols has many
   operational considerations.  This document attempts to collect and
   present the most critical and universal.  It is expected to evolve as
   BGPsec is formalized and initially deployed."

This is a relatively short document, 8 pages, full of wonder and
excitement! I hope that the wg members have read it (it's been through
8+ revisions) and that they will re-read it quickly, provide comments
as appropriate and ideas on preparedness for publication or not.


Thanks for you time and attention to this matter,

-Chris
co-chair-persona

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