Re: [GROW] Proposing a well-known BGP community for Anycast

[Joel Jaeggli]

On 7/9/22 10:11, Warren Kumari wrote:





On Sat, Jul 09, 2022 at 6:33 AM, Robert Raszuk  wrote:

Hi,

While it may sound like I am against it - I am not. I am just
trying to make sure what we ship can actually effectively work.

One key question for example which no one answered so far is this:

If I have one very important service for which I would like to use
ANYCAST address across my geo distributed load balancers does this
make my entire /24 or /22 I advertise any ANYCAST prefix ? I hope
not.


Unless I'm misunderstanding this completely, the community doesn't 
"make" a prefix an ANYCAST prefix, it simply **marks** (denotes) it as 
being used for anycast — this is subtle, but important to note, and 
seems to have caused some confusion in discussions. It an 
informational tag that people can use for debugging to to apply policy...


So, I have some prefixes where the backing aggregate is anycast 
(2a04:4e42::/32 for example) and 
the more specifics are unicast or anycast. I would be fine notionally, 
marking  prefix announcements based on how they are announced; we tag 
them with an opaque community value that indicates which pop the 
announcement comes from already for example which we can observe via 
various looking glasses etc...


This might be convenient for an outsider looking at the routes but it 
doesn't really tell you anything about what to do with them (nor should it).


But, getting back to your question — the smallest v4 prefix you can 
realistically announce[0] on the Internet is a /24, and so the 
smallest granularity you can mark at is the same.
So, if you are only using one address out of a /24  as an "anycast" 
address **and for some reason you want to use this to mark the address 
as being anycast** you will have to tag the whole /24. If you are only 
announcing a /22, you could have to have 2 announcements, with one of 
the /24's tagged, or you could tag the whole /22.


Generally when one is talking about Anycast one is talking about it at 
a prefix level anyway (and often it is "these sites are announcing the 
same address space and aren't intending to carry traffic between sites").
E.g: Let's say you have 192.0.2.0/24 , and most 
of the addresses are assigned to single machines, other than 
192.0.2.17, which you has assigned both to a machine in LA and 
Singapore. Technically 192.0.2.17 is anycast, but that's not something 
that you need to or should share with the outside world - it's not 
helpful for other people to use to build their routing policy towards 
you...



W
[0]: Pedant: Acshually, you can announce fairly much whatever, but the 
the smallest prefix people are likely to accept…




100s of hosts within my blocks may use high volume torrent which I
really do not need to ANYCAST at the network/routing layer - I use
geo extensions in the DNS for it.

So just asking simple operational question - when do we mark
prefix block as ANYCAST ?

I think if we are serious about actually helping ANYCASTs perhaps
we should allow to advertise those addresses separate from
allocated PI or PA blocks  For PA it will get aggregated. For
PI it will a little bit pollute the table - I guess this is why
the current version of the draft says that ANYCAST prefixes will
be advertised with NO-EXPORT community.

Thx,
R.








On Sat, Jul 9, 2022 at 11:37 AM Alejandro Acosta
mailto:alejandroacostaal...@gmail.com>> wrote:

Hello,

   After reading the draft and the comments on the list. I
think this is
going to be useful and will make BGP take better decisions. +1
to move
this draft forward.

   I wonder about the misuse of the community ANYCAST when the
prefix
being announced is not actually an anycast prefix, can be
there a kind
of abuse from some operators?. Do we need -if not out there
already- a
list of public anycasted prefixes (and I believe I have seem this
question somewhere).


Regards,


Alejandro,


On 5/7/22 5:40 AM, Maximilian Wilhelm wrote:
> Hey folks,
>
> after some discussion at RIPE84 we took the time to
formalize a draft
> to define a well-known BGP community to indicate a given
prefix is
> carrying Anycast traffic. The intent is to allow ISPs to do well
> informed TE, especially in cases where they want to diverge
from the
> hot potato principle.
>
> You can find the draft at
>
>
https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/

>
> Happy to share this at the upcoming meeting and hear your
thoughts!
>
> Thanks and best,
   

[GROW] draft minutes. ietf 112

[Joel Jaeggli]

I place these in the ietf notes app:

https://notes.ietf.org/notes-ietf-112-grow

pretty short so it shouldn't be hard to review.

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

Re: [GROW] Making BMP registries FCFS

[Joel Jaeggli]

Sent from my iPhone

> On Sep 20, 2018, at 22:33, Christopher Morrow  
> wrote:
> 
> Hello Grow Folks,
> This seems like a sane plan ... I or Job can either unilaterally accept this, 
> or ask for adoption...
> 
> If there's enough immediate call to avoid the 2wk call for adoption I'd be 
> happy to just put it on the docket...

I think you can adopt it and move on.  Support making registries low effort as 
a general principle.
> 
>> On Thu, Sep 20, 2018 at 1:12 AM John Scudder  wrote:
>> Hi All,
>> 
>> A while ago we talked about this. I finally wrote a draft for it, 
>> https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt:
>> 
>> Abstract
>> 
>>This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>>making a change to the registration procedures for several
>>registries.  Specifically, any BMP registry with a range of
>>32768-65530 designated "Specification Required" has that range re-
>>designated as "First Come First Served".
>> 
>> It's super short, 3 pages including all the boilerplate. I'd like to propose 
>> it as a WG item (and ideally, move it quickly to WGLC).
>> 
>> Thanks,
>> 
>> --John
>> 
>> P.S.: I'm one of the designated experts for those registries ("Specification 
>> Required" requires designated experts who review all requests). So I have 
>> the ulterior motive of trying to get rid of work. :-)
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7948 (5366)

[joel jaeggli]

On 5/23/18 10:16 AM, Warren Kumari wrote:
>
>
> On Wed, May 23, 2018 at 1:09 PM Nick Hilliard  > wrote:
>
> This errata report isn't wrong, but belongs to a bigger category of
> problems relating to how the IETF handles third party references
> in RFCs.
>
> It's unlikely that the researchgate url will be persistent in the
> longer
> term, at least any more than any other URL.
>
>
> ​I marked it as Hold for Document Update -- this seems to be the
> "best" way to annotate documents with things like this. ​
>
More generally the citation accurately describes the paper. At some
point in the future when we are long dead, it will still be a reference
to the paper.

Assuming that there is a method by which we can stably maintain
references to documents through URLs over the course of decades is
misguided.

> Thanks!
> W
>
>  
>
>
> Nick
>
> RFC Errata System wrote:
> > The following errata report has been submitted for RFC7948,
> > "Internet Exchange BGP Route Server Operations".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5366
> >
> > --
> > Type: Technical
> > Reported by: Greg Skinner  >
> >
> > Section: 6.2
> >
> > Original Text
> > -
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> >             Estrin, "A Route Server Architecture for Inter-Domain
> >             Routing", 1995,
> >             .
> >
> > Corrected Text
> > --
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> >             Estrin, "A Route Server Architecture for Inter-Domain
> >             Routing", 1995,
> >  > publication/
> > 2297181_A_Route_Server_Architecture_for_Inter-Domain_Routing>
> >
> > Notes
> > -
> > The paper is no longer accessible from the www.cs.usc.edu
>  site.  A related paper can be accessed at
> https://doi.org/10.1016/S0169-7552(98)8-7
>  by those who
> are registered members or will pay for the paper.  It would be
> cited as:
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> >                    Estrin, "A Route Server Architecture for
> Inter-Domain
> >                    Routing", Computer Networks and ISDN Systems,
> Volume 30,
> >                    Issue 12, 13 July 1998, Pages 1157-1174,
> >                   
>  >.
> >
> > Sorry, I had to split the link in the corrected text to satisfy
> the 72-character line length requirement in the corrected text.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7948 (draft-ietf-grow-ix-bgp-route-server-operations-05)
> > --
> > Title               : Internet Exchange BGP Route Server Operations
> > Publication Date    : September 2016
> > Author(s)           : N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker
> > Category            : INFORMATIONAL
> > Source              : Global Routing Operations
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org 
> > https://www.ietf.org/mailman/listinfo/grow
> >
>
>
>
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

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

Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

[joel jaeggli]

On 1/17/18 18:56, Randy Bush wrote:
> really do not want to get drawn into this.  but while looking into lags
> a few years back, we found a lot of them split across line cards, with
> resilience to line card failure being the stated reason.

even in fixed configuration 1 and 2ru switches you may split them across
asics for survivability and fabric / forwarding capacity reasons.

> randy
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

[Joel Jaeggli]

Sent from my iPhone

> On Jan 9, 2018, at 07:50, Job Snijders  wrote:
> 
>> On Tue, Jan 09, 2018 at 03:34:46PM +, Will Hargrave wrote:
>> On 9 Jan 2018, at 11:35, Job Snijders wrote:
 Our suggestion for handling LAGs looks like this: Typically, a
 minimum number of port members can be defined for a LAG being up.
 The LAG is not touched by BGP Session Culling during a maintenance
 unless this number is undercut. If the number if undercut the LAG
 is handled by BGP Session Culling as defined in the Internet
 Draft.

This sounds like an implementation specific detail to me. I can think of 
several variants on  selecting which bgp sessions to cull based on criterion 
that might be exchange specific. Such as when inter-switch/site bandwidth drops 
below a certain threshold cull peers accordingly. 

I’m not sure that I would recommend any of these however the specifics of a 
service offering are up to an operator.

 
 If no value for the minimum number of active port members is
 defined for a LAG, the value 1 should be used as this is the
 behaviour of LAGs today already.
>>> 
>>> Is this in context of multi-chassis LAG?
>> 
>> I think if we include anything about LAGs we should make it very clear
>> that you must apply the culling ACL to *either* all ports of a LAG
>> *or* none.  Applying it to half of an MCLAG could be disastrous.
> 
> Will, my reading of Thomas' message is slightly different, I don't think
> he is proposing to apply culling ACLs on half the ports of a LAG, he
> proposes that culling ACLs are only applied (to all ports) when more
> than X members of a LAG will be impacted by the maintenance (where X is
> an ixp-participant configurable number).

The same approach applies across multiple line cards in a large switch, or 
indeed might involve the loss of ports to which the client is not directly 
connected.

> 
>> I didn’t realise there were IXPs using MC-LAG. Discovering this maybe
>> surprise some members.
> 
> Thomas, in terms of IETF logistics, the RFC-To-Be 
> draft-ietf-grow-bgp-session-culling
> document has already been submitted to the RFC Editor and is in the
> queue, information on LAGs cannot be added at this point to the
> publication.
> 
> However, since this is a BCP, the next iteration could include
> additional information as our understanding of the culling practise
> improves, and the BCP number wouldn't change of course.
> 
>> From what I read in your message your organisation is still in the early
> phases of applying the 'culling' mechanism. I recommend you to (over
> time) carefully take notes of the interaction between LAG and culling,
> and whatever arises as the best current practise is documented in the
> next revision of the BCP.
> 
> Kind regards,
> 
> Job
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 

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

Re: [GROW] working group last call draft-ietf-grow-bgp-gshut

[joel jaeggli]

I support publication. there's not much more to it.
joel

On 7/24/17 17:13, Peter Schoenmaker wrote:
> Hi Grow,
> 
>  
> 
> As discussed in the working group meeting in Prague,
> draft-ietf-grow-bgp-gshut is ready for last call.  The last call will be
> 3 weeks ending August 11^th 2017.  Please review the document and
> provide feedback.
> 
>  
> 
> The document is at
> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/
> 
>  
> 
> Thanks
> 
>  
> 
> Peter & Chris
> 
>  
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[joel jaeggli]

On 5/6/17 10:53 AM, Warren Kumari wrote:
> [ + authors ]
> 
> On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk  wrote:
>> Hi Warren,
>>
>>> This is clearly not unanimous/ not everyone is happy, but (in my view)
>>> there is *rough* consensus for this to progress.
>>
>>
>> The group of users of BGP which this update impacts the most are members
>> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
>> to all AFI/SAFIs.

I think this statement elides that the largest impact here is on
operators, which might be participants of either working group but are
by in large not at the ietf.

As an operator the ability to make recommendations based on practice
that has proven to be problematic is ought to be something others in the
ietf would be interested in. e.g. default accept policies have been
shooting operators in the foot with v4 and v6 unicast AFI's since
literally the dawn of time.

> I'll happily admit that I have not been following BESS at all, and so
> know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
> if BESS is affected to the level that they should have been explicitly
> invited to comment?
> 
>> IMO before you progress anywhere with this IETF LC BESS WG should express
>> their formal opinion on it.
>>
>> Example of in or out eBGP policy where you are sending MAC addresses in
>> EVPN AF needs to be provided and explained why it makes sense. Likewise
>> examples of RTC AF for L3VPN Inter-as needs to be discussed.
>>
>> Otherwise the group of people which defined a lot of non ISP uses of BGP may
>> be
>> suddenly surprised down the read for keeping them out of the loop and have
>> customers loosing reachability upon compliant non sequential router OS
>> upgrade.
> 
> The authors are busy incorporating some final edits (including some
> suggested by Alvaro). I would have hoped that all affected parties
> would have seen the discussions on GROW / IDR / the IETF LC.
> 
> I ask people to please withhold judgment until the new version is released.
> 
> 
> I'm about to board a plane (to Budapest), and will be out of email for
> many hours...
> W
> 
>  >
>> Cheers,
>> Robert.
> 
>>
>> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
>>
>>
> 
> 
> 




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

Re: [GROW] Genart last call review of draft-ietf-grow-large-communities-usage-06

[joel jaeggli]

On 4/19/17 1:52 AM, Stewart Bryant wrote:
> 
> 
> On 19/04/2017 02:06, Randy Bush wrote:
 5.  Security Considerations

 Operators should note the recommendations in Section 11 of BGP
 Operations and Security [RFC7454].

 SB> You do not address the question of whether there are new
 SB> considerations, or considerations that are of increased importance?
>>> It is my understanding that RFC 8092 "BGP Large Communities" are just
>>> like RFC 1997 "BGP Communities", but ...  larger (for lack of better
>>> words). Referencing RFC 7454 seems plenteous.
>>>
>>> So, what if there are not any additional considerations, If there were,
>>> they would've been (or are) covered in RFC 8092's security section,
>>> right?
>>>
>>> This is an Internet-Draft targetted for Informational status, I'm not
>>> sure what you expect here.
>>>
 SB> Is there is text somewhere that discusses the integrity and
 SB> synchronization of the parameters and any consequences that arise?
>>> the what now? Can you elaborate on the above?
>> you're supposed to guess
>>
>> the normal hack here is
>>
>>this document introduces no new security issues beyond those discussed
>>in 1997
> 
> Guessing is horrible, but if that is what you do, that is what you do,
> and if the risks are the accepted norm in the BGP
> community I am fine.
> 
> Is corruption (deliberate or otherwise) of the community strings
> something that BGPsec will address?

That seems like a dubious premise given that they are optional. One can
simply remove them and substitute / add additional ones if you so
inclined and that occcurs in the normal course of events.

> - Stewart
> 




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

Re: [GROW] call for adoption draft-evens-grow-bmp-adj-rib-out

[joel jaeggli]

On 4/28/17 7:34 PM, Randy Bush wrote:
> while i support adoption of this work, two notes:
> 
>   o i should declare an involvement with the openbmp cabal for which
> this is key
> 
>   o clue bat please.  as this changes what is transported over bmp, why
> is it not in idr?

7854  itself was pursued in grow. (eventually, there's a long gap
between 2005 and 2016)

iirc the rational applied then i think as now is it's monitoring tool
not a routing protocol.

> 
> randy
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[joel jaeggli]

On 1/15/17 6:35 AM, Marco Marzetti wrote:
> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli  wrote:
>> On 1/14/17 3:58 AM, Marco Marzetti wrote:
>>> Joel,
>>>
>>> So you don't want your upstreams to honor RPKI just because they're
>>> 3rd parties between you and the other end?
>>
>> An ixp route-server is not a transit provider, all of the nexthops
>> exposed are in fact peers. So no I do not consider such a  device an
>> "upstream" it exists to service the policy needs of the peers on the
>> fabric  rather than that of the exchange operator.
>>
> 
> You can easily do the same in transit providers by disabling next-hop-self.

Nope, The router expressing nexthop self retains the available nexthops.
Under no circumstance is the router-server in the forwarding path, were
it, the route-server would be an upstream.

> 
>> I would  expect that a ixp route server that had a state policy of
>> validating rpki would not propagate invalid routes.
>>
>>> In the context of IXPs: instead of peering with the RS you should
>>> setup direct sessions with your partners if you really want to do
>>> prefix/path validation by yourself.

Consider the case where the invalid route masks an valid but longer path
from being advertised via the route server as the best path. in that
case the validating route-server is facilitating a prefix hijacking
which it would not have, had it discarded the route. You might argue
that this is no worse than not validating, however I think that is a
somewhat dubious point given that the rib on the route-server would show
otherwise.

>> No, I setup bilateral peering arrangements because they actually load
>> balance to my multiple ports, because the loci of control is
>> unambiguous, because it facilitates greatly build per session prefix
>> filters, and because they converge the control and forwarding path,
>> which has a tendency to fail much more gracefully in the face of l2
>> failures in distributed exchange fabric designs then does the route-server.
>>
> 
> Aren't we saying the same thing?
> Bilateral peering brings more control over what you send and receive.

we have a similar concurrence respecting the advantages. We appear to
differ on whether the route server offering a feature or not confers a
similar outcome.

> I just take an additional step and say that RPKI should be part of the
> default decision process of RSs

To confer the advantage you need to not allow invalid routes into your
best path selection processing.

> Regards.
> 
>>> Regards
>>>
>>>
>>> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli  wrote:
>>>> On 1/13/17 1:54 PM, Marco Marzetti wrote:
>>>>> 
>>>>> Every time one suggests a change related to the IXPs world we spend
>>>>> days arguing if it affects the neutrality and how.
>>>>> Do we really need that?
>>>>> 
>>>>>
>>>>> Anyway, i can't see why IXPs can blackhole traffic (if the destination
>>>>> requests it), but cannot do the same with prefixes.
>>>>> After all if a prefix is invalid the owner requested it to be verified
>>>>> by the other parties.
>>>> In general the consequences for IX operator that either allows it
>>>> customers to attack each other over the exchange route-server or does so
>>>> itself seems severe. Loss of confidence in the disposition of one's own
>>>> routes seems like immediate grounds for depeering. If the routes remain
>>>> afterwards with the short as path; the operator is engaged in prefix
>>>> hijakcing.
>>>>
>>>> I personally find it dubious that I would choose to honor a third
>>>> parties efforts at origin validation if I did not myself validate them
>>>> but a signal from the exchange that it did validate the origin or that
>>>> there an invalid roa floating around is at a minimum very interesting.
>>>>> I suggest to default to drop and, if possible, to switch to announce
>>>>> with community if the peer requests it (for instance someone may want
>>>>> to collect invalid routes for analysis).
>>>>>
>>>>>
>>>>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
>>>>>>> Adding grow@ietf.org for reality check.
>>>>>> no comment :)
>>>>>>
>>>>>> when you choose to use a route server [0], you have out-sourced much of
>>>>>> your policy and operational responsib

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[joel jaeggli]

On 1/14/17 3:58 AM, Marco Marzetti wrote:
> Joel,
> 
> So you don't want your upstreams to honor RPKI just because they're
> 3rd parties between you and the other end?

An ixp route-server is not a transit provider, all of the nexthops
exposed are in fact peers. So no I do not consider such a  device an
"upstream" it exists to service the policy needs of the peers on the
fabric  rather than that of the exchange operator.

I would  expect that a ixp route server that had a state policy of
validating rpki would not propagate invalid routes.

> In the context of IXPs: instead of peering with the RS you should
> setup direct sessions with your partners if you really want to do
> prefix/path validation by yourself.

No, I setup bilateral peering arrangements because they actually load
balance to my multiple ports, because the loci of control is
unambiguous, because it facilitates greatly build per session prefix
filters, and because they converge the control and forwarding path,
which has a tendency to fail much more gracefully in the face of l2
failures in distributed exchange fabric designs then does the route-server.

> Regards
> 
> 
> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli  wrote:
>> On 1/13/17 1:54 PM, Marco Marzetti wrote:
>>> 
>>> Every time one suggests a change related to the IXPs world we spend
>>> days arguing if it affects the neutrality and how.
>>> Do we really need that?
>>> 
>>>
>>> Anyway, i can't see why IXPs can blackhole traffic (if the destination
>>> requests it), but cannot do the same with prefixes.
>>> After all if a prefix is invalid the owner requested it to be verified
>>> by the other parties.
>> In general the consequences for IX operator that either allows it
>> customers to attack each other over the exchange route-server or does so
>> itself seems severe. Loss of confidence in the disposition of one's own
>> routes seems like immediate grounds for depeering. If the routes remain
>> afterwards with the short as path; the operator is engaged in prefix
>> hijakcing.
>>
>> I personally find it dubious that I would choose to honor a third
>> parties efforts at origin validation if I did not myself validate them
>> but a signal from the exchange that it did validate the origin or that
>> there an invalid roa floating around is at a minimum very interesting.
>>> I suggest to default to drop and, if possible, to switch to announce
>>> with community if the peer requests it (for instance someone may want
>>> to collect invalid routes for analysis).
>>>
>>>
>>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
>>>>> Adding grow@ietf.org for reality check.
>>>> no comment :)
>>>>
>>>> when you choose to use a route server [0], you have out-sourced much of
>>>> your policy and operational responsibilities.  seems to me that whether
>>>> this includes security decisions is a contract between the user and the
>>>> route server.
>>>>
>>>> so i might tell the server to drop invalids.  if i do not take that
>>>> (configurable, i presume) option, having the server mark them seems
>>>> helpful.
>>>>
>>>> randy
>>>>
>>>> --
>>>>
>>>> 0 - i suspect none of job, carlos, or i do.  so this is the experts
>>>> telling other people what they should do. :)
>>>>
>>>> ___
>>>> GROW mailing list
>>>> GROW@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/grow
>>>
>>>
>>
>>
> 
> 
> 




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

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[joel jaeggli]

On 1/13/17 2:53 PM, Job Snijders wrote:
> On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote:
>> On 1/13/17 1:54 PM, Marco Marzetti wrote:
>>> 
>>> Every time one suggests a change related to the IXPs world we spend
>>> days arguing if it affects the neutrality and how. Do we really
>>> need that?
>>> 
>>>
>>> Anyway, i can't see why IXPs can blackhole traffic (if the
>>> destination requests it), but cannot do the same with prefixes.
>>> After all if a prefix is invalid the owner requested it to be
>>> verified by the other parties.
>> In general the consequences for IX operator that either allows it
>> customers to attack each other over the exchange route-server or does
>> so itself seems severe. Loss of confidence in the disposition of one's
>> own routes seems like immediate grounds for depeering. If the routes
>> remain afterwards with the short as path; the operator is engaged in
>> prefix hijakcing.
>>
>> I personally find it dubious that I would choose to honor a third
>> parties efforts at origin validation if I did not myself validate them
>> but a signal from the exchange that it did validate the origin or that
>> there an invalid roa floating around is at a minimum very interesting.
> I still don't understand how there can be a justification as to why it
> would be OK for route servers to redistribute poisonous routes and say
> "trust me its OK i added a community!", and we expect some different
> behaviour from 'the rest of the AS's'?
>
> In a case like this 
> http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html,
> assuming a ROA had existed for 206.125.164.0/22, what would've been the
> appropiate response from any AS involved (including route servers)?
>
> A) "its fine, i tagged it with a community and amplified the problem
> by propagating it to all my peers"
>
> B) "the buck stops with me, the invalid route will not be propagated by 
> me"
>
> At the very least, i'd prefer the default mode should be a secure mode,
> not a 'scientifically interesting' mode.
I do wonder about the rational for saying "this is invalid, but here you go"

if I'm validating ROAs and my posture is that I don't accept routes with
invalid ROAS then I'm not taking any action on the basis of this
community. If I don't  validate, I'm not taking any action on the basis
of this community.
> Kind regards,
>
> Job
>




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

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[joel jaeggli]

On 1/13/17 1:54 PM, Marco Marzetti wrote:
> 
> Every time one suggests a change related to the IXPs world we spend
> days arguing if it affects the neutrality and how.
> Do we really need that?
> 
>
> Anyway, i can't see why IXPs can blackhole traffic (if the destination
> requests it), but cannot do the same with prefixes.
> After all if a prefix is invalid the owner requested it to be verified
> by the other parties.
In general the consequences for IX operator that either allows it
customers to attack each other over the exchange route-server or does so
itself seems severe. Loss of confidence in the disposition of one's own
routes seems like immediate grounds for depeering. If the routes remain
afterwards with the short as path; the operator is engaged in prefix
hijakcing.

I personally find it dubious that I would choose to honor a third
parties efforts at origin validation if I did not myself validate them
but a signal from the exchange that it did validate the origin or that
there an invalid roa floating around is at a minimum very interesting.
> I suggest to default to drop and, if possible, to switch to announce
> with community if the peer requests it (for instance someone may want
> to collect invalid routes for analysis).
>
>
> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
>>> Adding grow@ietf.org for reality check.
>> no comment :)
>>
>> when you choose to use a route server [0], you have out-sourced much of
>> your policy and operational responsibilities.  seems to me that whether
>> this includes security decisions is a contract between the user and the
>> route server.
>>
>> so i might tell the server to drop invalids.  if i do not take that
>> (configurable, i presume) option, having the server mark them seems
>> helpful.
>>
>> randy
>>
>> --
>>
>> 0 - i suspect none of job, carlos, or i do.  so this is the experts
>> telling other people what they should do. :)
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>
>




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

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[joel jaeggli]

On 11/29/16 11:31 AM, Randy Bush wrote:
> why do folk block syslog/514?
because spoofing syslog entries is a thing. in general I don't let
member of the general public emit junk into my logs except of course
spammers who are quite well represented albeit indirectly, as is the
case here.
> who can come up with the first exploit based on a tricky entry?
it's a fairly narrow surface area on the syslog reciver given the
emitter is the routers syslogd so for example something like

http://www.rsyslog.com/remote-syslog-pri-vulnerability/

is under the control of the syslogd not the sender.

128 characters is of somewhat limited value in syslog spoofing as you
have to flap you bgp session in order to emit a new line.

do you think reciver operation should be more tightly specified in some way?

thanks
joel
> randy
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>




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

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[joel jaeggli]

On 11/20/16 3:21 PM, Robert Raszuk wrote:
>
>
> > I'd like to ask the chairs to move
> 'draft-ietf-idr-operational-message-00' to 'Dead' status.
>
> It bothers you so much that it is a WG doc ?
>
> Or is the issue that it does not define fixed field for plain
> telephone number to dial ?
>
Not revved since 2012 seems like a problem.

To me the sticking point with expressing more complex information as
with proposed dump state and control tlvs involves the opportunity to
hose up signaling in new interesting ways.

Whether I think they should be more expressive or not; job's proposal
has the inherent safety of arriving on a cease which I'm pretty sure
doesn't leave much to the imagination.

> R.
>
>
>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr





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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[joel jaeggli]

On 11/15/16 12:48 PM, Job Snijders wrote:
> On Tue, Nov 15, 2016 at 03:12:40AM +, Sriram, Kotikalapudi (Fed) wrote:
>> My response marked with [Sriram] below.
>>
>> [Gert] Having implementations that could tack arbitrary "RPF lists" to
>> an interface would be very nice, but this is more like "auto-generate
>> ACLs based on prefix info" than "RPF" which stands for "reverse path
>> filter" (not sure about the "filter" bit, though)
>>
>> [Sriram] Current Feasible Path uRPF makes use of announced prefixes to
>> creates RPF tables of permitted source addresses on specific
>> interfaces, and our enhanced FP uRPF also does the same, but with some
>> more intelligence built in.

generating prefix lists for peers is something done out of band...

e.g. by bgpq3

the information does not exist in the routing system to do that e.g. for
prefiexes which are not presently announced or not announced to you, in
particular before sessions are established.

> Does this technique make routers self-aware? What exactly is meant with
> the word 'intelligence' in this context?
>
> Kind regards,
> 
> Job
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[joel jaeggli]

On 11/13/16 8:12 PM, Nick Hilliard wrote:
> joel jaeggli wrote:
>> The case where routine maintance creates temporary blackholes is
>> basically ubiquitious were you attempting to use urp strict.
> 
> oh indeed - I've been at the receiving end of exactly this type of
> blackholing.  Very annoying.  But I just wonder if urpf is the best tool
> to hammer this particular nail in.  Sriram implicitly points out that
> the term "customer cone" is a rather vague concept, and once you add the
> vagaries of peering cones, it gets a lot worse.  From an anecdotal point
> of view, people route traffic all over the place, and the further you
> get away from the traffic endpoints, the more difficult
> source-validation filtering becomes.
> 
> I suspect Sriram's proposed methodology is not going to be as useful as
> it might seem in production networks because he's making an assumption
> that the list of valid source paths can be built up by creating a union
> of all source ASNs and applying that to the union of all interfaces
> which are identified as feasible paths, intersected with the list of
> interfaces with feasible path urpf enabled.  Going back to his diagram,
> what if AS1 announces a prefix over a different transit e.g. AS6, but
> not AS4 or AS5?  Then they issue traffic with a source address from that
> prefix. The only way to handle this situation is with loose urpf, which
> is a nice way of saying that enhanced urpf would cause breakage in this
> situation.

Yeah, loose, ends up being the limit of was is feasible; you might as
well deploy a bogon filter drop martians, and not bother.

> I'm raising this because we run an as112 server at INEX and we've
> observed a surprisingly large quantity of traffic directed towards the
> anycast address from IP addresses from all over the world which come
> over the IXP fabric, but which we can't imagine how it arrives there,
> e.g. traffic from apnic + latam regions, etc.  While I appreciate that
> this is anecdotal, it's a real enough observation for me to suspect that
> the level of decoupling between bgp announcements (i.e. return path
> traffic) and forward path routing is something that would cause enhanced
> urpf to cause blackholing on production networks.

The preference of some networks to trump regional  preference with free,
to participate in mlpe exchages, without announcing routes on them, or
to selectively announce routes only to certain participants, while
witholding them from others makes all sort of wierd stuff appear there.
it makes to hard or more likely impossible to apply such filtering on
IXP ports.

In our case, where we generate prefix list filters for all routes that
we accept into the rib at exchange points we are naturally not even
going to have all of the paths that may potentially be available there.

> Nick
> 




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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[joel jaeggli]

On 11/11/16 8:12 AM, Nick Hilliard wrote:
> Sriram, Kotikalapudi (Fed) wrote:
>>> right, ok - I misunderstood.  So you're suggesting that the control
>>> plane correlates asns to interfaces and does something like
>>> creating a higher cost alternative path out each candidate source
>>> interface (based on ASN, as determined in the control plane) to
>>> allow the urpf mechanism handle this using its normal lookup
>>> method?
>>
>> Yes, that is correct.
> 
> I can't help feeling that the use case looks a bit contrived.  The sort
> of situations that could benefit from urpf that I've seen on production
> networks don't generally involve inconsistent prefix sets being
> announced via different connectivity providers, where there is a
> requirement for urpf away from the leaf network.
> 
> If it's any help, the most usual situation where urpf would be handy but
> can't be done, is where you have an interface facing an upstream and you
> want to receive prefixes (and send traffic) via that interface but not
> announce anything (or receive traffic).

The case where routine maintance creates temporary blackholes is
basically ubiquitious were you attempting to use urp strict.

> Nick
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] ietf 97 agenda

[joel jaeggli]

On 11/12/16 11:53 AM, Christopher Morrow wrote:
> howdy grow folks, I uploaded a draft agenda, things will likely
> change... here's the data so far:
> 
> 1 - Admin data / Draft Status10 min
> 2 - Grow-Bgp-reject - job 5 min
> 3 - Large-Communities - job  15 min
> 4 - opsec-urpf-improvements - sriram 15 min
> 5 - Why doesn't IDR know about Ops Requirements? 10 min

interested in this one. especially what we can take away that's
actionable from the discussion.

> happy to accept changes/updates/etc. we have a 1hr slot... my math says
> there's 5 min left, though we can re-adjust some as required.
> 
> -chris
> 
> 
> On Thu, Sep 29, 2016 at 7:15 AM, Peter Schoenmaker  > wrote:
> 
> Hello,
> 
> __ __
> 
> IETF 97 is fast approaching.  At IETF 96 in Berlin we did not meet. 
> GROW is planning to meet in Seoul if we have agenda items.  People
> who would like time on the agenda please send a request so that a
> time slot and agenda can be prepared.
> 
> __ __
> 
> thanks
> 
> __ __
> 
> peter & chris
> 
> __ __
> 
> __ __
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org 
> https://www.ietf.org/mailman/listinfo/grow
> 
> 
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Terry Manderson's No Objection on draft-ietf-grow-blackholing-03: (with COMMENT)

[joel jaeggli]

On 8/15/16 5:44 PM, Terry Manderson wrote:
> Terry Manderson has entered the following ballot position for
> draft-ietf-grow-blackholing-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work in addressing my concerns, clearing my DISCUSS.

Thanks much.
joel


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

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[joel jaeggli]

On 8/11/16 7:42 AM, Job Snijders wrote:
> Hi Nick,
>
> On Thu, Aug 11, 2016 at 03:34:00PM +0100, Nick Hilliard wrote:
>> Job Snijders wrote:
>>> Thank you for your time and reiew! I'm responding to your first in this
>>> thread, in context of the wealth of information provided as follow-ups
>>> to this email.
>> are these changes published anywhere, e.g. ietf datatracker or github?
> Thank you for your interest.
>
> We maintain the latest (living) version here
> https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/
> until we receive further instructions from the AD when and how to post
> a new version.
If that works for everyone. then I'm going to assume that steven will
clear at some point. and that terry wil lclear when this is posted. and
we can move on.

joel
> Kind regards,
>
> Job
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

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

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Joel Jaeggli]

Sent from my iPhone

> On Aug 8, 2016, at 15:37, Stephen Farrell  wrote:
> 
> 
> Sorry for the slow response here, had some distraction.
> 
> Responses to two of the bits of my discuss below. I need to read
> more of the thread to figure where we are with point (1)...
> 
>> On 03/08/16 17:02, Christopher Morrow wrote:
>> On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell 
>> wrote:
>> 
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-grow-blackholing-02: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> 
>>> First, I have to say that I'm pretty ignorant about
>>> practical routing operations, so my plan is to briefly
>>> discuss this and to then probably move to an abstain
>>> position, unless the issues I raise resonate with folks
>>> who are expert in this space.
>>> 
>>> (1) I agree with the points raised in IETF LC that the
>>> transitive nature of this proposal has dangers that may
>>> outweigh its utility. Was there discussion in the WG about
>>> potential solutions that do not have the transitivity
>>> property? If so, can you point me at those? If not, is
>>> there a reason to think no such solution is feasible?  (I
>>> suspect the answer may be "no" which is the main reason I
>>> plan to move to an abstain ballot.)
>> 
>> your tools to do signaling in bgp are ... limited you can toggle/adjust/etc
>> things such as:
>>  community
>>  origin
>>  metric
>>  prefix-itself
>> 
>> In the scenario where we want to enable one provider to signal to the other
>> provider: "please take this action"
>> 
>> community is the 'best' option... you can signal somethign meaningful with
>> a commnuity where origin/metric don't really allow you to do more than
>> binary decisions.
>> 
>> In a scenario on the wider network NOT at a peering fabric that has a
>> route-server thingy... you don't really need a 'transitive' attribute
>> because you're just telling your neighbor: "pls do this" to which they
>> presumably have policy to do the right thing (or they may choose to ignore
>> you, of course).
>> 
>> In the scenario that includes a peering-fabric and route-server, you need
>> either:
>>  1) route-server to do some kinky things (ignore some forms of
>> non-transitive, re-map something to the non-transitive, etc)
>>  2) pass the attribute through because it is transitive.
>> 
>> the route-server is the remote network's bgp peer, so you have to ask the
>> route-server to ship stuff across to other peers...
>> 
>> 
>>> 
>>> (2) IIUC, this proposal envisages BGP speakers commonly
>>> telling others to blackhole specific /32's or /128's. And
>>> of course as the draft says BGP doesn't provide us with a
>>> way to "prevent the unauthorized modification of
>>> information by the forwarding agent." Given those two
>> 
>> err, there is MD5 auth for tcp... which SHOULD prevent modification
>> in-flight.
>> of course (ha!) there's notionally tcp-AO which should do the same thing,
>> perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
>> darn! no implementations of AO exist.
>> 
>> 
>>> things, this scheme seems to be an ideal new way to cause
>>> any service that advertises a fallback to actually fall back,
>> 
>> with bgp being in a state where there is no method (there is, md5 auth) to
>> prevent/notice modifications... all bgp sessions are at risk (some risk).
>> 
>> 
>>> e.g to use a secondary MX or DNS resolver rather than a
>>> primary. That seems like a fine way to try and possibly
>>> succeed in attacking many possible things.  The discuss
>>> point here is to ask if this really is a new attack
>>> vector, and if so, if the appropriate level of analysis of
>> 
>> doesn't look new to me, no. and 'worse', today someone COULD just (if they
>> are in the right place and can do bgp packet creation,etc) just tag all of
>> your announcments to your provider(s) with the local provider version of
>> this community, blackholing all of your traffic... or they could change the
>> announcements to withdrawals... or other mean things. the addition of this
>> blackhole community doesn't change this problem, at all.
> 
> Sorry, I'm not seeing that. Are you saying all BGP speakers
> can today commonly know exactly how to ask blackhole *any*
> individual /32 or /128?
> 
> If so, then surely that calls into question the utility of
> specifying this community

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Joel Jaeggli]

Sent from my iPhone

On Aug 4, 2016, at 14:55, Randy Bush  wrote:

>> fine, bad terminology.  was following the original.
> 
> the document is not strong on rigor
> 
>> Is it not possible to define a ROA that includes a prefix-length
>> -or-longer up-to and including a /128 or /32?
> 
> quite possible.  but
> 
>>> rpki-based origin authentication doe not help here because the
>>> attacker requesting my prefix be blackholed with merely forge my AS
>>> on the path.

It's a leaky bucket, peers can generate prefix list filters for their route 
objects. If they send spurious junk it's associated with their down-stream cone 
not someone else's. If they're insufficiently good at filtering, their 
customers can jack each other. It's transit providers there's no point in 
filtering the Internet cone from. 

The threat of more specific  routes arriving from your transits with wacky as 
paths is real but that's prefix hijacking today and 20 years ago.

> 
> randy
> 

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

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[joel jaeggli]

On 8/3/16 7:11 PM, Christopher Morrow wrote:
> 
> 
> On Wed, Aug 3, 2016 at 9:16 PM, Terry Manderson
> mailto:terry.mander...@icann.org>> wrote:
> 
> Terry Manderson has entered the following ballot position for
> draft-ietf-grow-blackholing-02: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-hestitancyhestitancygrow-blackholing/
> 
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Firstly, thank you for documenting operational practice.
> 
> With regards to section 3.3:
> 
> "BGP speakers SHOULD only accept and honor BGP announcements
> carrying the
> BLACKHOLE community .."
> 
> 
> I'd note (and I'm surprised no one else noted already, especially you)
> this odd bit of language:
> (I'm mad I didn't see it earlier as well, actually)
> 
>   "It has been observed that announcements of IP prefixes larger than
>/24 for IPv4 and /48 for IPv6 are usually not accepted on the
>Internet (see section 6.1.3 [RFC7454]).  However, blackhole routes
>should be as small as possible?"
> 
> So: "Large prefixes == /24 or /48"
> but: "small prefixes == /32 or /128"
> 
> err, small/large, long/short... there's inconsistent use of these terms
> here, I think. At the least it's a bit confusing.
> I'd have stuck with:
>   "It has been observed that announcements of IP prefixes LONGER than
>/24 for IPv4 and /48 for IPv6 are usually not accepted on the
>Internet (see section 6.1.3 [RFC7454]).  However, blackhole routes
>should be as LONG as possible"
> 
> (I prefer longer/shorter for prefix stuff)
> 
> So, back to your discuss though:
>   "BGP speakers SHOULD only accept and honor BGP announcements carrying
>the BLACKHOLE community if the announced prefix is covered by a
>shorter prefix for which the neighboring network is authorized to
>advertise."
> 
> (note that 'shorter' is used here...again making the above bit more
> confiusing with smaller/larger)
> 
> MUST vs SHOULD for this, I do think the MUST would be easy to handle. Is
> this a problem in an RS situation? Probbaly not... on the RS, but on the
> distant peer, it likely is hard(er) to deal with. I don't imagine many
> folk prefix filter the RS session very tightly only because memberships
> come/go and you may not always get timely notice (I have no idea when
> people come/go at the IX's I connect to).

public route servers can have quite well developed per peer prefix
filtering, if it's built on route objects, the adjacent peers on the
other hand probably do not since they don't know apriori what's on the
other side all the time.

likewise internal to a datacenter or a network under one span of control
you may have quite relaxed import filtering between a bunch of private
ASNs. but a very narrowly controlled export policy facing the world.

> So, SHOULD makes some sense to me, at least in the RS peer/distant-peer
> world. Surely for direct BGP peerings MUST is a better idea, I think.
> 
> 
> I really question why this is a "SHOULD" and not a "MUST", even in an
> informational RFC. Is the ability for a transit provider so loose that
> appropriate route filters from a peer ASN can't be applied so that
> only a
> "SHOULD" is practical? In which case I do question the sanity of making
> such a recommendation and thus service available if some other ASN might
> be able to inject the route and affect another service, even by mistake.
> Potentially if RPKI is in use, then a peer AS might be able to validate
> the announcement against a ROA. But it strikes me that this is not the
> machinery you would want to tack on in this case.
> 
> 
> job and I chatted a bit about this (oddly, prior to your note here) and
> one thing to keep in mind with RPKI is that the ROA Owner (publisher?)
> would have to first know their special-prefix was going to be attacked,
> then set the ROA up (as a /32 or as a supernet -> /32). I'm skeptical of
> that being done, certainly today there are virtually no /32 ROA in the
> system.
> 
> RPKI probably isn't the tool to use here, for this.

you're not likely to do that for /128s in any event.

> 
> The same could be said for section 3.2. I would be rather wary of NOT
> adding a NO_ADVERTISE (at the very least) and to be honest SHOULD still
> seems far too loose for me. Almost all of the recipe's that 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[joel jaeggli]

On 8/3/16 8:31 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-grow-blackholing-02: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> 
> First, I have to say that I'm pretty ignorant about
> practical routing operations, so my plan is to briefly
> discuss this and to then probably move to an abstain
> position, unless the issues I raise resonate with folks
> who are expert in this space.
> 
> (1) I agree with the points raised in IETF LC that the
> transitive nature of this proposal has dangers that may
> outweigh its utility. Was there discussion in the WG about
> potential solutions that do not have the transitivity
> property? If so, can you point me at those? If not, is
> there a reason to think no such solution is feasible?  (I
> suspect the answer may be "no" which is the main reason I
> plan to move to an abstain ballot.)

transitivity is a required property if n > 2 ASNs are involved in the
propagation of the message...

There are deployed examples that depend on this property.

> (2) IIUC, this proposal envisages BGP speakers commonly
> telling others to blackhole specific /32's or /128's. And
> of course as the draft says BGP doesn't provide us with a
> way to "prevent the unauthorized modification of
> information by the forwarding agent." 

The applies to all learned routes in the internet. operational practices
that prevent leakage and limit the damage of prefix hijacking also
prevent the opportunity for leakage of more specific routes or
inappropriately sourced advertisements. any member of the of the routing
system may simply synthesize a routing update for any prefix and
propagate it subject to the policy constraints imposed by their
neighbors every interceding ASN must necessarily modify the update
before propagating it..

> Given those two
> things, this scheme seems to be an ideal new way to cause
> any service that advertises a fallback to actually fall back,
> e.g to use a secondary MX or DNS resolver rather than a
> primary. That seems like a fine way to try and possibly
> succeed in attacking many possible things.  The discuss
> point here is to ask if this really is a new attack
> vector, and if so, if the appropriate level of analysis of
> its impact has been done?

it is not, imho, an attack using a prefix tagged with the community is a
prefix hijacking. if you accept the route with our without the community
you are installing it in you table and selecting a nexthop in one case
the nexthop is your discard, in the other the nethop is a another router.

> If this is new, then I don't see
> that the security considerations text adequately describe
> the range of possible attacks that could be mounted using
> this scheme. (As an aside, I wonder if asking to blackhole
> /32's and /128's might impact on routing table sizes and
> if something ought be said about that?)

a transit ASN might accept but generally will not without coordination
propagate prefix's longer than a  /24 or a /48. so in a global sense no.
configured max prefix limits which providers use a circuit breaker are
likely to discourage spamming updates at your neighbor, as does the fact
that by definition you want connectivity for your prefix.

> (3) Given that there are dangers associated with this
> mechanism, why is there no statement in the draft that
> actions taken based on this scheme ought be logged or
> otherwise publicised as a possible way to provide some
> level of accountability, even if only after the fact?
> 
> 
> --
> COMMENT:
> --
> 
> 
> - 3.2: It isn't clear to me how one might exercise
> "extreme caution" here - can you explain? Or is that
> obvious to the intended audience of this?
> 
> 




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

[GROW] Finishing up the last call for draft-ietf-grow-blackholing

[joel jaeggli]

Folks,

During the IETF last call there were signficant concerns raised with
this draft resulting in two revisions and a change in intended status to
informational. Criticism of the proposal revolved largly along two axis.

 * Advice on exchange point operation. This was largely removed.

 * Concern over the uncontrolled propigation of transitive attributes.

The latter can potentially be ameliorated but not removed while using
transitive attributes. I think importantly for this discussion,
widespread use of a mechanism like this using provider defined
communites  without the registration of the community poses similar risks.

My take on this is that despite present concerns we've achieved rough
consensus to advance this and should proceed accordingly.

Thank you all for your efforts, diligent review and sustained discussion
that has allowed us to arrive at this point.

joel



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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 7/1/16 5:29 AM, Randy Bush wrote:
>> why the security warning relating to denial of service attacks was
>> removed.
> 
> what could possibly go wrong with a well-known transitive attribute
> which causes an un-authenticated prefix's traffic to be dropped on the
> floor?

Today I have 5 or six of them... and my managment system has a series of
substitutions for the provider-appropriate one.  So, what can go wrong
with a poorly understood and loosely coordinated transitive attributes
which cause unauthenticated prefixes traffic to be dropped on the floor?

> randy
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/29/16 1:46 PM, Nick Hilliard wrote:
> Job Snijders wrote:
>> Should it be somehow clarified that router vendors are not supposed to
>> implement mechanisms, which are by default enabled, that discard traffic
>> for BLACKHOLE'ed prefixes?
> 
> I would have said the opposite, i.e. that any traffic tagged with this
> prefix is dropped via e.g. null0 or martian mechanisms / etc.  But it
> definitely needs to be defined because at the moment it's ambiguous.
> Ambiguity is fine when it's your own network, but not fine when you're
> defining something with global scope.
> 
> Also, as Michael Py mentioned, it's not clear whether this refers to
> source based blackholing or destination based blackholing.

It should be an inherent property that what is being blackholed is
traffic bound for the prefix that the community is attached to is it not?

Source based RTBH requires some  explicit coordination between the
parties using it.

> Nick
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/28/16 8:36 AM, Job Snijders wrote:

> Some IXPs can do actual blackholing inside their fabric, a mechanism
> which does _not_ require any of the IXP participants to participate or
> adjust their local routing policy to honor the BLACKHOLE community. I've
> described such a non-cooperative mechanism on the NANOG mailing-list and
> I know of one IXP which has implemented this. (This is different from
> DE-CIX's current implementation.)

sure l3 acls can be applied to l2 ports.

most ixps are going to have a set of filters that prevent certain kinda
of activity, e.g. spanning tree PDUs, router-advertisement, proxy-arp
and so  on. these are all within the technical capabilties of most
high-end-ethernet switch platforms.

> Already today, the reality is that some IXPs can and will blackhole
> traffic at the request of a participant, and some IXPs can't (vendor
> limitations) or won't (miscellaneous concerns) blackhole traffic. This
> draft does not change any of that.

agree

> Kind regards,
> 
> Job
> 




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

Re: [GROW] Cancel GROW IETF 96 Berlin

[joel jaeggli]

Thanks guys!

joel

On 6/28/16 8:30 AM, Peter Schoenmaker wrote:
> Hello,
> 
>  
> 
> The IETF 96 agenda is quite busy, and GROW does not have any pressing
> agenda items (read no agenda items at this time.)  As a result, the GROW
> meeting will be cancelled.  We will plan to meet at IETF 97 in Seoul.
> 
>  
> 
> Thanks
> 
>  
> 
> Peter & Chris
> 
>  
> 
>  
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/27/16 6:50 AM, Christopher Morrow wrote:
> 
> 
> On Mon, Jun 27, 2016 at 12:47 AM, joel jaeggli  <mailto:joe...@bogus.com>> wrote:
> 
> On 6/26/16 6:38 AM, Nick Hilliard wrote:
> > There has been no discussion on the GROW mailing list about having this
> > document published as Standards Track rather than informational and it's
> > coming as a surprise to see that this was only announced at IESG Last
> > Call a couple of days ago.  At the least, there ought to be some
> > discussion about this before pushing it up into the publication queue.
> 
> The looking back at the document that was WGLCed (which is the current
> version) the state was standards track. the individual sumbission draft
> draft-ymbk-grow-blackholing-00 was flagged as such since initial
> submission.  It's status therefore I think is well understood. Whether
> that's appropriate or not is another question.
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
> 
> ​has it marked as PS... which I too thought was correct.​

ps is the first step in standards track.

> ​-chris​
> 




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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/26/16 6:38 AM, Nick Hilliard wrote:
> There has been no discussion on the GROW mailing list about having this
> document published as Standards Track rather than informational and it's
> coming as a surprise to see that this was only announced at IESG Last
> Call a couple of days ago.  At the least, there ought to be some
> discussion about this before pushing it up into the publication queue.

The looking back at the document that was WGLCed (which is the current
version) the state was standards track. the individual sumbission draft
draft-ymbk-grow-blackholing-00 was flagged as such since initial
submission.  It's status therefore I think is well understood. Whether
that's appropriate or not is another question.

Afaik well know assignments (and there are precious few really) have
been generally regarded as standards action thought the ranges is split
like so.


Range   Registration Procedures
0x-0x8000   First Come First Served
0x8001-0x   Standards Action






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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/26/16 10:06 AM, John Kristoff wrote:
> On Sun, 26 Jun 2016 16:31:17 +
> joel jaeggli  wrote:
> 
>> It's not clear to me how that would even work. assuming for the sake
>> of arguement that the IXP by way of configured policy on the
>> route-server adds this community to a prefix.
> 
> Here is some detail on how DE-CIX implements it:
> 
>   <https://www.de-cix.net/products-services/de-cix-frankfurt/blackholing/>


At the the possible expense of belaboring my observation still further,
i'm aware of how the community is implemented, I'm on those fabrics.
What I wasn't and am not clear on is how that would lead to:

Nick

>>  In the case of route servers, blackholing turns the IXP into
>>  a legal target.

Job

> I feel that this is not the appropiate forum to define what IXPs can,
> can't, should and shouldn't in context of legal enforcement agencies.

Short of the IXP engaging in prefix hijacking, or unilaterally applying
the community to an existing prefix; the ixp is in not position to
black-hole traffic except on request of the sender of the desitnation
prefix. Likewise if you withdraw the prefix from the routeserver, the
blackhole goes away, unless the route-server is engaged in prefix hijacking.

I don't see either of those issues as serious threats. if you live under
a regime that considers prefix hijacking acceptable, the community adds
no capability that the exchange does not already have;they can afterall
change the nexthop today, announce whatever prefix you're willing to
accept and so on; any of those activities in most places would be
immediate grounds for depeering and departure.

> John
> 




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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[joel jaeggli]

On 6/26/16 7:43 AM, Job Snijders wrote:
> On Sun, Jun 26, 2016 at 03:23:53PM +0100, Nick Hilliard wrote:
>> Job Snijders wrote:
>>> Follow-up question: without section 3.4 - would you still object?
>>
>> I don't think that IXPs should be mentioned anywhere in this document.
>> For the general case of blackholing, an IXP is a clearing house so
>> should not get involved in the business of dropping its participants'
>> traffic. In the case of route servers, blackholing turns the IXP into
>> a legal target.
> 
> I feel that this is not the appropiate forum to define what IXPs can,
> can't, should and shouldn't in context of legal enforcement agencies.

It's not clear to me how that would even work. assuming for the sake of
arguement that the IXP by way of configured policy on the route-server
adds this community to a prefix.

If the route is withdrawn by the participant from the mlpe the
black-hole goes away...

Since the ixp doesn't control the prefix announcement the addition of
transitive attributes in a fashion counter to the wishes of the parties
involved seems self-defeating.

If the ixp mlpe is engaged in prefix hijacking (and that includes more
specifcs for announced blocks), well... that's not an exchange we deal
with anymore.

> Kind regards,
> 
> Job
> 




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

Re: [GROW] discuss about draft-luo-grow-ts-use-cases-00

[joel jaeggli]

On 5/23/16 4:41 AM, luoyuj.gd wrote:
> Hi everyone，
> 
>  
> 
> I'm Jenny Luo，one of the writers of draft-luo-grow-ts-use-cases-00.
> The draft is mainly about*usecases for traffic steering in operator
> network*, and we introduce it on 95th IETF meeting in *Buenos Aires.*
> 
> Our team received some comments and we appreciated very much for
> that.   The comments are listed as follows and we would like to discuss
> them with the relevant experts .  We would really appreciate it if you
> could offer more description about the comments, so we could understand
> them correctly.
> 
>  
> 
> * Comments:*
> ­1. The requirements are components that sometimes are impossible to
> implement.Concerns that transferring requirements to implementations are
> difficult. Fine granularity is a difficult implementation.
> ­ 2. With the right set of computation someone can do what is needed in
> a network.Heavily lifting needed to get it through
> ­ 3. Control system: Add a delay and a random generator
> ­ 4. What is the different to do it random. Other parties are working on
> other different constraintorgs.
> ­ 5. Delaying computation, Implementing at the edge and monitoring inside.
> ­ 6. Not everybody have sufficient resources. Can´t be emulated without
> resources.  How much spare capacity or overloading in your network? If
> you can afford serious spare capacity you can aprox. to a good
> contribution by delaying.

Not sure how these networks are architected, but in my experience
network cores are rarely over-subscribed unless degraded. interconnects
between network's may be but political/economic reasons for them being
so do not see like a great basis for coordination on traffic
engineering. so that leaves customer facing edges.


> ­ 7. How can we schedule flows automatically with fine granularity?
>  
> 
>   2016-05-20
> 
> 
> 
> *Jenny Luo*
> 
> Data Communication Research Department
> 
> Guangzhoou Research Institute of ChinaTelecom
> 
> Tel：+86 20 38639134
> 
> Mobile：18924152329
> 
> E-mail：luoyuj...@chinatelecom.cn 
> 
>  
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] consensus on BMP security IPSEc vs TLS

[joel jaeggli]

On 12/22/15 11:49 AM, Stephen Farrell wrote:
> 
> 
> On 22/12/15 19:41, Randy Bush wrote:
>>> And that's enough for me to clear my discuss too, yes.
>>>
>>> I guess saying IPsec is better than maybe badly specifying
>>> how to do TLS, even though TLS is the more sensible thing
>>> to do,
>>
>> and un-badly specifying tls is not possible?
> 
> I'd say entirely possible, given some interest and
> effort.

And of course implementation.

> S
> 
>>
>> randy
>>
> 




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

Re: [GROW] consensus on BMP security IPSEc vs TLS

[joel jaeggli]

On 12/22/15 9:47 AM, Stephen Farrell wrote:
> 
> 
> On 22/12/15 17:13, joel jaeggli wrote:
>> fwiw it works for me I guess.
> 
> And that's enough for me to clear my discuss too, yes.
> 
> I guess saying IPsec is better than maybe badly specifying
> how to do TLS, even though TLS is the more sensible thing
> to do,

If it goes towards addressing Kathleen's Discuss so much the better.


> S
> 
>>
>> On 12/16/15 2:51 PM, Peter Schoenmaker wrote:
>>> Hello,
>>>
>>> We have reached the final stretch for draft-ietf-grow-bmp, but have hit
>>> a hiccup with regards to the proposal on the mechanism specified to
>>> secure the data.  We need to reach consensus on the text in the draft.
>>>  There has been extensive discussion on the mailing list.  
>>>
>>> The authors have proposed the following text using IPSec:
>>>
>>> Replace: This document does not specify any security mechanism for BMP.
>>>
>>> With:  Where the security considerations outlined above are a concern, users
>>>   of this protocol should use IPsec [RFC4303] in tunnel mode with
>>>   preshared keys.
>>>
>>> Can participants affirm the text is sufficient to cover securing BMP
>>> data?  If you feel it is not sufficient, propose alternate text for the
>>> document.
>>>
>>> Thanks
>>>
>>> Peter
>>>
>>>
>>
>>
> 




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

Re: [GROW] consensus on BMP security IPSEc vs TLS

[joel jaeggli]

fwiw it works for me I guess.

On 12/16/15 2:51 PM, Peter Schoenmaker wrote:
> Hello,
> 
> We have reached the final stretch for draft-ietf-grow-bmp, but have hit
> a hiccup with regards to the proposal on the mechanism specified to
> secure the data.  We need to reach consensus on the text in the draft.
>  There has been extensive discussion on the mailing list.  
> 
> The authors have proposed the following text using IPSec:
> 
> Replace: This document does not specify any security mechanism for BMP.
> 
> With:  Where the security considerations outlined above are a concern, users
>   of this protocol should use IPsec [RFC4303] in tunnel mode with
>   preshared keys.
> 
> Can participants affirm the text is sufficient to cover securing BMP
> data?  If you feel it is not sufficient, propose alternate text for the
> document.
> 
> Thanks
> 
> Peter
> 
> 




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

Re: [GROW] Working Group Adoption Call: draft-petrie-grow-mrt-add-paths

[joel jaeggli]

On 11/3/15 7:12 AM, Susan Hares wrote:
> Multiple paths are a fact of life in many BGP deployments.  Please accept
> and publish soon. 

+1

> Sue Hares
> 
> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
> Sent: Monday, November 02, 2015 11:25 AM
> To: Jeffrey Haas
> Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org;
> grow-...@tools.ietf.org
> Subject: Re: [GROW] Working Group Adoption Call:
> draft-petrie-grow-mrt-add-paths
> 
> Mon, Nov 02, 2015 at 05:27:15PM +0900, Jeffrey Haas:
>>> Please consider this the start of a 3 week Adoption call for the 
>>> noted draft who's abstract is:
>>>   "This document updates the Multi-threaded Routing Toolkit (MRT) export
>>>   format for Border Gateway Protocol (BGP) routing information by
>>>   extending it to support the Advertisement of Multiple Paths in BGP
>>>   extensions."
>>
>> IMO, this one is a no-brainer.  I encourage adoption, swift editing and
> then ship as an RFC.
> 
> Agree with Jeff.
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

[joel jaeggli]

On 11/2/15 8:39 AM, Christopher Morrow wrote:
> oh well, since this conversation got re-ingnited..
> 
> On Sat, Oct 31, 2015 at 1:15 AM, Job Snijders  wrote:
>> I think "type 5: U-Shaped Turn with More Specific Prefix" should be
>> removed from the document.
>>
>> Given the description:
>>
>> "A multi-homed AS learns a route from one upstream ISP and announces
>> a subprefix (subsumed in the prefix) to another upstream ISP."
>>
>> I'd classify this type of announcement a "hijack" or "attack", not a
>> route leak.
> 
> this makes sense to me, this is the equivalent of several well known
> instances of someone's 'internap' box leaking outside their span of
> control. So, I agree this is a hijack, not a leak... though clearly
> the subnets were 'leaked' outside the span of control, the effect is
> really a hijack of the remote prefix.

hijack is the practical result of the more specific.

intent is of course something else.

> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

[joel jaeggli]

On 10/18/15 1:46 PM, Rob Shakir wrote:
> Hi Benoit, John,



> I agree with the sentiment here.
> 
> However, we need to consider how wide-ranging this discussion might
> end up being, and what the implications elsewhere might be. Let’s
> take a very simple example of the Per-Peer Header (§4.2) ‘Peer
> Distinguisher’.
> 
> The structure that the IETF is progressing towards is that we have a
> VRF-centric model for protocol configuration. That is to say that we
> have protocols that are rooted under a routing table, rather than
> vice-versa. This means that to be able to identify a particular peer,
> we need to distinguish the routing table to which it belongs (to find
> the correct routing table), and subsequently the address of the peer.
> The latter is fine, but the former is more problematic. For example,
> we may have a routing instance that does not have an RD specified
> (this is the case where we have VRFs that are not L3VPN VRFs). [0]

the scenario you describe inclusive of overlapping prefixes describes
a number of deployments.

> This would mean that we can’t key the lists in the same way - so is
> the ask simply that we are able to determine - based on the set of
> input data that is received from BMP - the object within the YANG
> model hierarchy that is being referenced? Or is it more wide than
> that, which says that BMP and YANG objects should be keyed the same?
> 
> I believe that the former is the only one that we can practically
> achieve - and in that case, only for a subset of cases.
> 
> If we can clarify the intention here, I can take a look at the
> mapping. From a first pass, I don’t see huge problems (other than
> some values in the BMP header are perhaps not relevant to BGP
> configuration/state in general).
> 
> The model that is perhaps as relevant as the models that Benoit
> mentioned is a model describing the BGP RIB - which should
> potentially have the same means of describing NLRI etc. such that
> they can be referenced (UPDATE in BMP message X can be referenced to
> entry in BGP RIB of router R). The RIB models that OpenConfig is
> working on are not (yet) published in the IETF:
> https://github.com/openconfig/public/tree/master/release/models/rib
> 
> Kind regards, r.
> 
> [0]: This might raise the question of what happens when we have
> multiple VRFs without RDs, but overlapping addressing in the BMP
> spec.
> 
> 




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

Re: [GROW] Kathleen Moriarty's No Objection on draft-ietf-grow-filtering-threats-07: (with COMMENT)

[joel jaeggli]

On 9/1/15 8:16 AM, Peter Schoenmaker wrote:
> 
>> 
>>> 
 
 Now if the unexpected path through A is under-provisioned,
 traffic will be lost. But that would be a bit strange for the
 owner of P to do the documented trick to trigger a DoS of its
 own prefix P, wouldn¹t it?
 
 So can I really talk about a DoS vector here? If someone else
 than the owner of P plays games with P to trigger the
 unexpected path for P through A, then it definitely becomes
 one, but there we fall in the classic cases of prefix
 hi-jacking.
>>> 
>>> I don't see a pointer in the security considerations to other
>>> work describing this threat as a consideration, should this be
>>> included? It sounds as if it should be.
>> 
>> 
>> Well, I have the feeling that it is quite out of the scope of this 
>> document, which is about playing with more specific prefixes
>> injection bound with restricted propagation. I am not sure I should
>> mention prefix hi-jacking here, as it¹s quite a different,
>> well-document approach; I inject a more specific prefix that
>> belongs to someone else and I drop the traffic.
>> 
>> I don¹t know what others think about this.
> 
> I would agree this is out of scope for the document.  The traffic
> makes it to the intended and correct destination.  There are no rogue
> players involved (at least more than normal which is covered
> extensively in other documents as pierre points out.)  The main point
> is how traffic is routed through different networks.

We worked pretty hard to keep both the attack terminology out of the
document and to keep the focus on the non-malicious action of ordinary
actors. I think it's better that we don't lump that in with malicious
action of varying varieties.

> peter
> 
> 
>> 
>> Cheers,
>> 
>> Pierre.
>> 
>> 
>>> 
>>> Thanks, Kathleen
>>> 
 
 Cheers,
 
 Pierre.
 
 
 The importance of mentioning this int he security 
 considerations section is to more explicitly call this out as
 a potential DoS attack method.  The time for BGP to repropagate
 might be short(ish), but that could be a critical amount of
 time during an event and maybe the more specific AS is a web
 server farm or some other critical resource.
 
 
 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Best regards, Kathleen
>> 
> 
> 




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

Re: [GROW] RtgDir Review: draft-ietf-grow-irr-routing-policy-considerations-05

[joel jaeggli]

It's been a long time in coming but we have an update to this draft
which I figured I would run by you, before we return it to the IESG.

draft-ietf-grow-irr-routing-policy-considerations-06

 is out

https://www.ietf.org/rfcdiff?url1=draft-ietf-grow-irr-routing-policy-considerations-05&url2=draft-ietf-grow-irr-routing-policy-considerations-06

On 11/24/14 3:44 PM, Terry Manderson wrote:
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review. The purpose of
> the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> 
> 
> Document: draft-ietf-grow-irr-routing-policy-considerations-05
> Reviewer: Terry Manderson
> Review Date: 2014-11-24
> IETF LC End Date: 2014-12-01
> Intended Status: Informational
> 
> Summary: 
> I have a handful of minor concerns about this document which should be
> resolved prior to publication, and a few comments centered around general
> draft direction.
> 
> 
> Comments: 
> I think the handling of the historical issues of IRRs is fair. There is
> often a reach to 'beat up' on the perceived faults of a system - this
> draft doesn't do this. Indeed I thought the first half of the draft was
> very well constructed and provides an appropriate discussion.
> 
> When discussing the data integrity (or lack thereof) of an IRR I feel
> insufficient attention is given to overall integrity of the IRR source,
> esp. wrt mirroring (sec 5.1). That is, are all the objects completely
> mirrored, is there a way to tell? why not? etc? As it is RIPE withhold
> certain objects for PII reasons, what else could be missing that is
> operationally important?
> 
> The lack of C.I.A. on the NRTM stream is touched on, but not given due
> attention. Additionally the lack of C.I.A on the current query side
> (WHOIS/TCP/43) should be iterated as a part of the attack surface, both
> for the IRR operator and the IRR user.
>  
> A number of times within the draft the similarities, differences, and
> 'nice to have' aspects between the IRR and the RPKI are highlighted. I'm
> left wondering if this topic actually needs its own section. For example:
> the RPKI has RPKI-RTR, yet that in itself will not carry policy based
> information. Without turning such a section into "what the RPKI doesn't
> do", some time spent highlighting what the IRR provides and what RPKI may
> provide could help the reader. The underpinning statement from the draft
> appears to be that RPKI origin validation is or could be good, but it
> (RPKI) currently is not scoped to replace RPSL and the nuanced policy
> applications which providers employ now. If this is a pragmatism holds
> true, then for completeness of the discussion the Authors and ADs might
> wish to include it.
> 
> 
> Major Issues: 
> No major issues found.
> 
> 
> Minor Issues: 
> Section 5, Para 4: I feel it is glib to state that "it can be observed
> that the most common circuit size used by ISPs is now 10 Gbps".
> Qualifying this with the economic development or network development of
> the region is prudent, or perhaps provide a reference to a survey if one
> exists.
> 
> Section 5.2, Para 5. I found the last sentence in para 5 difficult to
> parse. Please consider rewording.
> 
> Section 7.2, Para 2. Please consider re-writing the second sentence of
> this para. The (over) use of commas makes it hard to read.
> 
> Section 7.3, Para 1. I don't think you actually mean '"offline" server'..
> Perhaps "disparate"? or "configuration"??? Please clarify, or perhaps
> define the term in the context here. "offline" is an overloaded term.
> 
> Nits: 
> 
> Section 5.1, para 3: s/(Edge)/(edge)/
> Section 5.2, para 4: "turn-up", word suggestion: "commission"
> Section 5.2, para 4: s/call up/call/   (the "up" is superfluous)
> Section 6, para 4: s/take affect/take effect/ x2
> Section 7.2, para 4: s/so have the some of the scaling/so have some of the
> scaling/
> 
> Section 8: 1st sentence. I read this and thought: "the green leaf is
> green".. This might just be a style difference around over-stating the
> obvious.
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] Adrian Farrel's Discuss on draft-ietf-grow-irr-routing-policy-considerations-05: (with DISCUSS)

[joel jaeggli]

On 3/2/15 6:40 AM, McPherson, Danny wrote:
> 
> These are some pretty significant changes that themselves could be an
> internet-draft/document, methinks.  Perhaps those so interested in C.I.A
> in their comments could contribute some text, this was meant to be more
> operational.
> 
> I hope Eric has the cycles to resolve these [non-trivial comments] and if
> they did get resolved it¹d surely need to return to WG LC (IMO) ‹ and I¹d
> presuppose someone would find an opportunity to request a review from
> SIDR, although part of the intent was expressly to avoid beating that
> horse.

so, my assumption is a that discussing them isn't going always require
change, some of them probably will.

> I¹ll defer to Eric if he¹s going to be able to address these, but I can
> pretty much guarantee it won¹t see the RFC editor until well after Dallas
> (if ever, now).

If we can't resolve it under adrian, that's fine more or less becasue
the reviewer becomes the new AD but I probably get to rerun the IESG
evaluation, so for all our sakes I think that is expedient to clear the
discuss under the current regime but I am flexible.

> Alas, 
> 
> 
> -danny
> 
> 
> On 3/2/15, 1:51 AM, "joel jaeggli"  wrote:
> 
>> hello,
>>
>> would like to chase this one down and resolve it.
>>
>> http://www.ietf.org/mail-archive/web/grow/current/msg03015.html
>>
>> but haven't seen to much activity.
>>
>> lets do this thing and maybe we can publish this one before the upcoming
>> meeting.
>>
>> joel
>>
>> On 2/9/15 9:08 PM, joel jaeggli wrote:
>>> I'm under no illusion that terry's dicussion will have changed by the
>>> time he's installed.
>>>
>>> I would rather have it done sooner in any event.
>>>
>>> we did not get a change out prior ti the jan discussion and it stalled
>>> after that sorry.
>>>
>>> On 2/9/15 1:06 PM, Adrian Farrel wrote:
>>>> Hi,
>>>>
>>>> Any progress on this?
>>>>
>>>> Just in case you were holding out the hope that my Discuss will expire
>>>> when I leave the IESG, I have to point out that my Discuss was to make
>>>> sure that the RTG Dir review by Terry Manderson gets attention. And
>>>> Terry will show up on the IESG when I leave :-)
>>>>
>>>> Shame to see a document sitting when it is so close to being done.
>>>>
>>>> Adrian
>>>>
>>>>> -Original Message-
>>>>> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adrian Farrel
>>>>> Sent: 18 December 2014 15:33
>>>>> To: The IESG
>>>>> Cc: christopher.mor...@gmail.com; grow-cha...@tools.ietf.org;
>>>>> grow@ietf.org;
>>>>> draft-ietf-grow-irr-routing-policy-considerations@tools.ietf.org
>>>>> Subject: Adrian Farrel's Discuss on
>>>>> draft-ietf-grow-irr-routing-policy-
>>>>> considerations-05: (with DISCUSS)
>>>>>
>>>>> Adrian Farrel has entered the following ballot position for
>>>>> draft-ietf-grow-irr-routing-policy-considerations-05: Discuss
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>> this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>>
>>>>> http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-cons
>>>>> iderations/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> DISCUSS:
>>>>> --
>>>>>
>>>>> I'd like to see some discussion of the points raised by Terry
>>>>> Manderson
>>>>> in his Routing Directorate review during the IETF last call period
>>>>> (circulated on the Grow list at
>>>>> http://www.ietf.org/mail-archive/web/grow/current/msg03015.html).
>>>>>
>>>>> By preference this discussion should be between the authors, WG, and
>>>>> reviewer. But I'd be happy to step in and own the discussions if that
>>>>> will help.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 




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

Re: [GROW] Adrian Farrel's Discuss on draft-ietf-grow-irr-routing-policy-considerations-05: (with DISCUSS)

[joel jaeggli]

hello,

would like to chase this one down and resolve it.

http://www.ietf.org/mail-archive/web/grow/current/msg03015.html

but haven't seen to much activity.

lets do this thing and maybe we can publish this one before the upcoming
meeting.

joel

On 2/9/15 9:08 PM, joel jaeggli wrote:
> I'm under no illusion that terry's dicussion will have changed by the
> time he's installed.
> 
> I would rather have it done sooner in any event.
> 
> we did not get a change out prior ti the jan discussion and it stalled
> after that sorry.
> 
> On 2/9/15 1:06 PM, Adrian Farrel wrote:
>> Hi,
>>
>> Any progress on this?
>>
>> Just in case you were holding out the hope that my Discuss will expire when 
>> I leave the IESG, I have to point out that my Discuss was to make sure that 
>> the RTG Dir review by Terry Manderson gets attention. And Terry will show up 
>> on the IESG when I leave :-)
>>
>> Shame to see a document sitting when it is so close to being done.
>>
>> Adrian
>>
>>> -Original Message-
>>> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adrian Farrel
>>> Sent: 18 December 2014 15:33
>>> To: The IESG
>>> Cc: christopher.mor...@gmail.com; grow-cha...@tools.ietf.org; grow@ietf.org;
>>> draft-ietf-grow-irr-routing-policy-considerations@tools.ietf.org
>>> Subject: Adrian Farrel's Discuss on draft-ietf-grow-irr-routing-policy-
>>> considerations-05: (with DISCUSS)
>>>
>>> Adrian Farrel has entered the following ballot position for
>>> draft-ietf-grow-irr-routing-policy-considerations-05: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> I'd like to see some discussion of the points raised by Terry Manderson
>>> in his Routing Directorate review during the IETF last call period
>>> (circulated on the Grow list at
>>> http://www.ietf.org/mail-archive/web/grow/current/msg03015.html).
>>>
>>> By preference this discussion should be between the authors, WG, and
>>> reviewer. But I'd be happy to step in and own the discussions if that
>>> will help.
>>>
>>>
>>
>>
>>
> 
> 




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

Re: [GROW] Adrian Farrel's Discuss on draft-ietf-grow-irr-routing-policy-considerations-05: (with DISCUSS)

[joel jaeggli]

I'm under no illusion that terry's dicussion will have changed by the
time he's installed.

I would rather have it done sooner in any event.

we did not get a change out prior ti the jan discussion and it stalled
after that sorry.

On 2/9/15 1:06 PM, Adrian Farrel wrote:
> Hi,
> 
> Any progress on this?
> 
> Just in case you were holding out the hope that my Discuss will expire when I 
> leave the IESG, I have to point out that my Discuss was to make sure that the 
> RTG Dir review by Terry Manderson gets attention. And Terry will show up on 
> the IESG when I leave :-)
> 
> Shame to see a document sitting when it is so close to being done.
> 
> Adrian
> 
>> -Original Message-
>> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adrian Farrel
>> Sent: 18 December 2014 15:33
>> To: The IESG
>> Cc: christopher.mor...@gmail.com; grow-cha...@tools.ietf.org; grow@ietf.org;
>> draft-ietf-grow-irr-routing-policy-considerations@tools.ietf.org
>> Subject: Adrian Farrel's Discuss on draft-ietf-grow-irr-routing-policy-
>> considerations-05: (with DISCUSS)
>>
>> Adrian Farrel has entered the following ballot position for
>> draft-ietf-grow-irr-routing-policy-considerations-05: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> I'd like to see some discussion of the points raised by Terry Manderson
>> in his Routing Directorate review during the IETF last call period
>> (circulated on the Grow list at
>> http://www.ietf.org/mail-archive/web/grow/current/msg03015.html).
>>
>> By preference this discussion should be between the authors, WG, and
>> reviewer. But I'd be happy to step in and own the discussions if that
>> will help.
>>
>>
> 
> 
> 




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

Re: [GROW] [v6ops] Deaggregation by large organizations

[joel jaeggli]

On 10/16/14 7:59 AM, Gert Doering wrote:
> Hi,
> 
> On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote:
>>> A strong message to that extent would be good :-) - coupled with
>>> some recommendations how the conflicting goals ("I want all ISPs in
>>> my neighbourhood to use optimal routing" vs. "someone in Asia might
>>> not be interested in all in 5k routes for german municipality")
>>> could be solved.
>>
>> ok, perhaps iljitsch can drop some text into a document so we can get
>> a good read going and decide whether or not GROW wants to spend cycles
>> on it?
> 
> That would be nice (as I see the problem but have no cycles to write
> something useful).
> 
>> The problem exists in v4 and v6 and likely will persist in whatever
>> comes next. It's directly related to routing operations work on the
>> global intertubes, so it SEEMS like GROW is the 'right place' to
>> discuss this... we can't go anywhere without text and a draft though.
> 
> It seems to be made worse by the fact that "this" can be done more
> easily with IPv6, as you just can't get enough v4 space to subdivide
> it into 5000 globally visible prefixes today - and those entities that
> discover the "must have reliability!  must have independence!" mantra
> *now* will hit the v6 space...  (given that I see this argument in this
> dimension more often from governmental structures who have been hiding
> behind single-IPv4-NAT so far).

The number of autonomous systems present in the internet is a good proxy
for the number of organizations that find this necessary. It is not a
proxy for the number of prefixes each of those ASes choose to advertise
though somewhat less than half of those ASNs advertise one prefix only.

http://www.cidr-report.org/cgi-bin/plot?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-as-count%2etxt&start=0&end=1413472455&width=0%2e9&height=0%2e3&with=step&ylabel=AS+Count


>>> I get that question fairly often from "largish networks", and so far,
>>> I always have to answer "there is no routing police, so it's hard to
>>> say what is allowed on the Internet and what not" - which is a humorous
>>> way to say "there is no consensus here what consists 'good' and
>>> 'responsible'"...
>>
>> I sort of don't want there to be 'routing police' though :( In a way
>> this whole debate sounds like something a 'cisco training class' (or
>> other example) would have covered, or should cover. I suppose it's
>> fairly experiential at this point though.
> 
> I *do* want a routing police, in the sense that "the operator community"
> agrees on what is considered "good" and "bad" behaviour, so end users
> can ask someone (me, Iljitsch, ...) what to do in their network planning,
> and we can tell them
> 
>   - if you do *this*, it's "guaranteed" to work
>   - if you do *that*, you can be sure that you will be filtered
> 
> while today, I have to tell them
> 
>   - well, today it is likely to work, but it might stop working tomorrow,
> and there is no document that you could show around to those that
> break your connectivity to show them that "you are doing the right thing"
> 
> ISPs develop their own guidelines on prefix-length filtering, some with
> better understanding on what they want to achieve, others by using 10 year
> old example documents for never-updated filters...
> 
> So, yes, guidance, please :-)
> 
> Gert Doering
> -- NetMaster
> 
> 
> 
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 




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

Re: [GROW] Agenda for london ietf

[joel jaeggli]

Note all that the draft submission deadline is now just slightly less
than a month away

2014-02-14

thanks!


On 1/13/14, 5:29 AM, p...@lugs.com wrote:
> hi grow mailing list,
> Its that time again to look at agenda items for the meeting.  We did cancel 
> the meeting last ietf for lack of agenda items.  We do have a few outstanding 
> work items, and some new ones that would be useful to make progress on...
> -- BGP error handling  -- was 
> draft-ietf-grow-ops-reqs-for-bgp-error-handling-- BMP status -- last active 
> draft draft-ietf-grow-bmp-07.txt-- 
> draft-ietf-grow-ix-bgp-route-server-operations-01-- 
> draft-ietf-grow-filtering-threats-01 -- we had last call, and past but did 
> not receive any feedback on the list-- New work on RPSL attributes
> London would be a good opportunity to address many of these.
> Thanks
> peter & chris
> 
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 




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

Re: [GROW] adoption of draft-mynam-grow-diverse-path-impl as a WG document

[joel jaeggli]

On 5/7/13 4:18 AM, Jeff Tantsura wrote:

Hi,

Given draft-ietf-grow-diverse-bgp-path-dist has been published as RFC6774
and we have got 2 existing implementation - Cisco and Ericsson, I'd like
to ask for adoption
of draft-mynam-grow-diverse-path-impl as a WG document.
Seeing a implementation report against 03 when 6774 is draft 08ish is 
causing me moderate cognitive dissonance.




Thanks!

Cheers,
Jeff


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



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

Re: [GROW] Terminology in draft-cardona-filtering-threats-01

[joel jaeggli]

On 3/21/13 5:40 AM, Pierre Francois wrote:


Hello,

We got some feedback during the last grow session that the "policy violations" 
we describe in the draft
are not policy violations but forwarding states that one of the ISPs was not 
expecting to see across its network.

Would a renaming of "policy violation" into "unexpected forwarding state" 
across the draft do?
it's important I think, to describe from whose vantage point the state 
is unexpected. The path taken by traffic is a result of the expression 
of the policy applied by all the participants that influenced the path. 
The selective advertisement of more specific paths at the orgin for 
example is a deliberate act on the part of the originator to influence 
path selection whether for performance, arbitrage or other preference 
reasons that aren't expressed in the bgp routing system...


Mistakes I think readily produce unexpected results, if you do something 
wrong it's likely produce a result you didn't expect.

Cheers,

Pierre.

PS: We were also thinking about "non software defined paths" :-D

All the paths are defined by software.



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



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

Re: [GROW] New Version Notification for draft-manderson-routing-intent-00.txt

[Joel jaeggli]

On 8/22/11 23:28 , Terry Manderson wrote:
> Hi Pedro,
> 
> 
> On 23/08/11 5:53 AM, "Pedro Torres"  wrote:
> 
>> Dears,
>>
>> I don't know if GROW WG is the best place to suggest such
> 
> My feel is that it is. So this is where I've started - I've emailed the
> Chairs, AD, IAB, IETF separately to investigate.
> 
>> modifications to IANA but I appreciate Terry I-D.
>> Acctually we see these things in IANA IPv4 Address Space Registry:
>> 192/8 Administered by ARIN
>> 172/8 Administered by ARIN
>>
>> Was 192.168/16 or 172.16/12 allocated by ARIN?
>>
> 
> See RFC1918. ARIN was started in Dec 1997 from memory. So I think RFC1918
> predates ARIN. Those who were around then might be able to shed light.
> (Although I think who came first is irrelevant to this draft)

As RC 1918 states the prefixes were allocated by IANA, 10/8 was the
arpanet before it was shut off.

You will note that one of the authors worked for the RIPE NCC which did
exist at the time.

>> I really appreciate the idea to show more specific allocations in this
>> IANA document.
>> I am not sure if the column PRI is the best way to do this but a new
> 
> The PRI was the simplest option that is easy to understand I could come up
> with.
> 
>> way to show ALL IANA allocated prefixes with a reasonable designation
>> could be nice.
> 
> I think so too.
> 
> Cheers
> Terry
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 

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

Re: [GROW] New Version Notification for draft-manderson-routing-intent-00.txt

[Joel jaeggli]

On 8/23/11 08:06 , Nick Hilliard wrote:

> Would it not be better to approach this problem from a completely different
> direction?  E.g. to formally recommend that end users consider everything
> routable except address space defined in RFC 3330 + its successors + the
> equivalent for ipv6?  And then perhaps to put in some scary wording about
> the terrible consequences of using address space on your network that has
> been assigned to other organisations?

+1

> Nick
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 

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