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

[Christopher Morrow]

Jumping in a bit late, but... (and only for this one point really)

On Thu, Oct 15, 2015 at 7:35 AM, Jeffrey Haas  wrote:
>> Why is using TLS not a no-brainer for this?  Given the likes
>> of the Belgacom and Gemalto reports, I would love to

TLS is a great plan, now you have to:
  1) get certificates to devices (and keys)
  2) mint said certs from your internal CA (probably, maybe)
  3) update ca certificate data on devices and clients
  4) check AND FAIL WHEN BAD THINGS HAPPEN certs presented to clients

TLS is great, but its not simple in operational use especially if you
want to deal with the full lifecycle of the tls world.

The above only matters (really) for 'inside my span of control' bmp
monitoring (to my devices from my servers, etc), and doesn't apply in
a sane fashion to the 'public service' bmp providers.

>> understand why people are still willing to buy and sell
>> equipment without such basic features. The "explanation"
>> that nobody needs it or nobody provides it seems off base
>> here - this is new code and a new interface, and the

where's tcp/ao support in the vendor gear in the field?
where's tcp/ao support in even one popular unix derivative? windows?

I'd love to do AO for this and bgp and my ssh sessions and such...
but... there's zero support for a protocol that landed in RFC (where
are it's 2 competing implementations? how did it make it to Standard
without running code?) in june 2010.

>> relevant security protocols (SSH, IPsec and TLS) are all
>> nearly or more than 20 years old.

it's not clear that ssh is viable here, it's also clear that IPSEC is
fairly heavyweight and likely not in the code path for management /
control-plane traffic on devices, and TLS has it's host (above) of
lifecycle issues.

The security stuff is important, by verbiage alone, but by actually
useful code and standards? not so much.

The BMP draft says:
  "Where the security considerations outlined above are a concern, users
   of this protocol should consider using some type of transport that
   provides mutual authentication, data integrity and transport
   protection, such as IPsec [RFC4303] or TCP-AO [RFC5925].  If
   confidentiality is considered a concern, a transport providing that
   as well could be selected."

which actually seems spot on, despite my ranty-bits above.

is it time to lift the DISCUSS here? or can we go around the rosebush
again about how we would love better security in a world where we are
clearly not important enough to actually get better security by
default?

-chris

___
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)

[George, Wes]

I just went hunting for an instance of this in IETF land, and only found
references related to two hosts talking to one another from behind the
same NAT.
So, I went hunting on the internet, and everywhere I saw an explanation,
it was of the variant "going out the same interface it came in on" and
used U-turn synonymously. I was unable to find a reference to a definition
as I outlined below. That's not necessarily an issue but we may need to
explain the term before we use it so that there is no confusion.

Thanks,

Wes


On 10/31/15, 10:07 PM, "Sriram, Kotikalapudi"
 wrote:

>Wes,
>
>Thanks, Wes, for taking another look.
>And thanks for laying out some interesting (and entertaining) alternative
>names
>that  can to used instead of "U-Turn".
>Like we discussed in the hallway this morning, it makes sense to use
>"Hairpin Turn"
>instead of "U-Turn", especially considering "Hairpin Turn" has been used
>in the VPN context.
>
>Sriram
>
>
>
>From: George, Wes 
>Sent: Friday, October 30, 2015 10:01 AM
>To: Sriram, Kotikalapudi
>Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org;
>grow-...@tools.ietf.org
>Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>(ends: 8/24/2015 - Aug 24)
>
>On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi"
> wrote:
>
>
>Sriram, this is significantly improved. One substantial comment that I
>still have with this version:
>
>>>It is also unclear from the text exactly what you mean by U-Turn
>>>(it's not going back the way it came, so actually hairpin might be a
>>>better term),
>>>so a few words to clarify might be useful.
>>
>>Hairpin seems to have a connotation that the turn is tight/constricted.
>>So now I use the phrase “U-shaped turn” instead of “U-turn”.
>
>WG] This may be nitpicking, but I don't think that adding "shaped" is
>actually much of an improvement. I was thinking of hairpin from the way
>that it is used in VPNs, as in data that enters and leaves the network via
>the same edge device, but typically on a different physical or logical
>interface (instead of entering on one PE and leaving via another), rather
>than the way that it is used on racetracks to describe a near 180 degree
>turn.
>Here are a few ideas I had of other ways to refer to this:
>
>-  a "detour leak", in that traffic will be detouring through the leaking
>ASN
>-  "ASN-in-the-middle leak" - similar to MiTM such that invoking the
>concept is useful, but it's necessary to disambiguate the two since the
>latter has a specific and well-known meaning
>-  "parrotting leak" or "game of telephone leak" in that it is repeating
>something it learned elsewhere, but introducing a mistake, not unlike the
>grade school game of telephone (if you're up for a reference to The
>Simpsons, you could call it a "purple monkey dishwasher leak" but that
>would likely require too much explanation ;-) )
>-  "[accidental | unintentional] transit leak" since the net result of the
>leak is that traffic will transit the leaking AS rather than its normal
>path
>
>
>Thanks,
>
>Wes
>
>
>Anything below this line has been added by my company’s mail server, I
>have no control over it.
>---
>
>
>
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
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)

[Christopher Morrow]

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.

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

[GROW] draft-mauch-bgp-reject

[Jared Mauch]

I plan on covering this briefly in the GROW meeting today and uploaded the 
revised text that has been sitting in my output queue since August.

This is basically codifying the fact that you MUST NOT default to "bgp 
unsafe-ebgp-policy” for any BGP speaking device.

- Jared
___
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)

[David Farmer]

Thinking about this a bit, I prefer "hairpin turn" over "U-turn".  In my mind a 
"hairpin turn" is talking about a tight turn in a road and by necessity a tight 
turn for the traffic on the road, the road itself turns back on itself.  Where 
as a "U-turn" talks about a tight turn traffic makes on road, usually to 
reverse direction on the road or where only the traffic is turning back on 
itself.  Put another way, you can make a "U-turn" on a perfectly strait road, 
but you can't make a "hairpin turn" on a strait road.

In the Internet we have a different term for a "U-turn", we generally call that 
a "loopback".  Therefore I think "hairpin turn" is the most appropriate in this 
case, unless we really mean a "loopback".

Whichever term we use, it should be clearly defined, it should be obvious at 
this point there is no clear unambiguous common understanding to rely on here.

Thanks.

-- 
===
David Farmer  Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===


> On Nov 1, 2015, at 07:02, George, Wes  wrote:
> 
> I just went hunting for an instance of this in IETF land, and only found
> references related to two hosts talking to one another from behind the
> same NAT.
> So, I went hunting on the internet, and everywhere I saw an explanation,
> it was of the variant "going out the same interface it came in on" and
> used U-turn synonymously. I was unable to find a reference to a definition
> as I outlined below. That's not necessarily an issue but we may need to
> explain the term before we use it so that there is no confusion.
> 
> Thanks,
> 
> Wes
> 
> 
> On 10/31/15, 10:07 PM, "Sriram, Kotikalapudi"
>  wrote:
> 
>> Wes,
>> 
>> Thanks, Wes, for taking another look.
>> And thanks for laying out some interesting (and entertaining) alternative
>> names
>> that  can to used instead of "U-Turn".
>> Like we discussed in the hallway this morning, it makes sense to use
>> "Hairpin Turn"
>> instead of "U-Turn", especially considering "Hairpin Turn" has been used
>> in the VPN context.
>> 
>> Sriram
>> 
>> 
>> 
>> From: George, Wes 
>> Sent: Friday, October 30, 2015 10:01 AM
>> To: Sriram, Kotikalapudi
>> Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org;
>> grow-...@tools.ietf.org
>> Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>> (ends: 8/24/2015 - Aug 24)
>> 
>> On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi"
>>  wrote:
>> 
>> 
>> Sriram, this is significantly improved. One substantial comment that I
>> still have with this version:
>> 
 It is also unclear from the text exactly what you mean by U-Turn
 (it's not going back the way it came, so actually hairpin might be a
 better term),
 so a few words to clarify might be useful.
>>> 
>>> Hairpin seems to have a connotation that the turn is tight/constricted.
>>> So now I use the phrase “U-shaped turn” instead of “U-turn”.
>> 
>> WG] This may be nitpicking, but I don't think that adding "shaped" is
>> actually much of an improvement. I was thinking of hairpin from the way
>> that it is used in VPNs, as in data that enters and leaves the network via
>> the same edge device, but typically on a different physical or logical
>> interface (instead of entering on one PE and leaving via another), rather
>> than the way that it is used on racetracks to describe a near 180 degree
>> turn.
>> Here are a few ideas I had of other ways to refer to this:
>> 
>> -  a "detour leak", in that traffic will be detouring through the leaking
>> ASN
>> -  "ASN-in-the-middle leak" - similar to MiTM such that invoking the
>> concept is useful, but it's necessary to disambiguate the two since the
>> latter has a specific and well-known meaning
>> -  "parrotting leak" or "game of telephone leak" in that it is repeating
>> something it learned elsewhere, but introducing a mistake, not unlike the
>> grade school game of telephone (if you're up for a reference to The
>> Simpsons, you could call it a "purple monkey dishwasher leak" but that
>> would likely require too much explanation ;-) )
>> -  "[accidental | unintentional] transit leak" since the net result of the
>> leak is that traffic will transit the leaking AS rather than its normal
>> path
>> 
>> 
>> Thanks,
>> 
>> Wes
>> 
>> 
>> Anything below this line has been added by my company’s mail server, I
>> have no control over it.
>> ---
>> 
>> 
>> 
>> 
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject to
>> copyright belonging to Time Warner Cable. This E-mail is 

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

[Sriram, Kotikalapudi]

>There's seemingly 1 comment set not responded to on-list (job's last),
>but overall support seems positive. 

I have just posted responses to Job's comments.

>I'll ship a document shepherd
>review northbound post-ietf-meeting week.

Thank you.

>by then sriram should have an updated revision with comments dealt
>with as well I beleive?

Yes, we can co-ordinate that. Thanks.

Sriram

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

[GROW] Agenda for today's meeting

[Christopher Morrow]

Howdy!
For the folk in Yokohama, we posted the agenda yesterday, I think
there's only one presenter planned? (Thomas and blackhole community
work)

If there are others please speak up 'now' (with slides as well
please), I probably forgot a presenter and 'search your mail for the
right phrase' is failing me currently :( So... if you think you are
supposed to be presenting please speak up sooner rather than later :)

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

Re: [GROW] WG Adoption: draft-ymbk-grow-blackholing (expires: 08/26/2015 - Aug 26)

[Christopher Morrow]

howdy!
after a long delay this pops out the 'adoption call' chute as 'adopted'.
The authors can spin a re-named draft when the gates re-open for draft
submission (probably monday?) and we can progress along as we should.

thanks for reading the draft, providing comments and
support/no-support commentary.
-chris

On Thu, Aug 13, 2015 at 5:55 AM, Christopher Morrow
 wrote:
> Howdy Grow folk,
> Thomas and his co-editors are looking for support/not-support for:
>   
>
> who's abstract is:
>   "This document describes the use of a well-known Border Gateway
>Protocol (BGP) community for blackholing at IP networks and Internet
>Exchange Points (IXP).  This well-known advisory transitive BGP
>community, namely BLACKHOLE, allows an origin AS to specify that a
>neighboring IP network or IXP should blackhole a specific IP prefix."
>
> we have had a lively discussion on-list and in the last meeting in
> Prague, it'd be great to have some discussion about adoption and then
> a decision on/about 8/26 (august 26th).
>
> Thanks!
> -chris
> co-chair

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

[GROW] IETF94 GROW meeting notes

[Job Snijders]

Notes from the IETF94 GROW meeting in Yokohama, Japan.

Chairs: Christopher Morrow & Peter Schoenmaker
Jabber: Colin Petrie, Notes: Job Snijders

#0 Thomas King - draft-ymbk-grow-blackholing 

King offers background information on why a standardized blackhole
BGP community is useful. Presents on different methods current
implemented by various organisations: each one uses different
communities for the same function.

65535:666 is (still) the desired identifier for the well-known community.

As far as King knows there are no outstanding comments/remarks.

Morrow indicates that the draft will probably soon proceed to next-call.

#1 Colin Petrie - MRT/BGP Add-Paths draft-petrie-grow-mrt-add-path

In IDR people work on draft-ietf-idr-add-paths. This brings new NLRI
encoding for BGP messages, negotiated via capabilities. 

Problem statement: Current MRT parsers cannot know how many bttes
should be in the NLRI. You can reverse engineer how many bytes it
should read for that field, if you scan back (possibly several
weeks) to the negotiated capabilities in the OPEN messages.

Proposal: add new SubType codes to signal to the parser how to
interpret the NLRI and MP_NLRI fields.

Peter asks the room whether there is support to adopt the document
as GROW working group doc. The room is positive about adopting, no
objections.

#2 Jared Mauch - draft-mauch-bgp-reject

"An EBGP speaking device MUST NOT advertise routes without
configured policy". Some router vendors already conform to the
draft: IOS XR & JunOS.

Mauch is looking for home/working group for the document.

Manning suggests that the document should not limit itself to eBGP
but to any and all BGP. The room near unanimously reacts with "no".

Volk (DT) appreciates the draft, and wonders what other advice
implementors need to create proper: e.g. sementics of well-known
communities is often not honored by default.

Schoenmaker asks the room whether there is support to make the
document a working group document. There is strong support in the
room to take this on.

End of meeting: 15:50 local time.

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

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Job Snijders]

On Mon, Nov 02, 2015 at 05:57:54PM +1100, Christopher Morrow wrote:
> Howdy Grow folk (again),
> Please consider this as the start of a 3wk working group adoption call
> for the subject draft who's abstract is:
> 
>   "This document defines the default behaviour of a BGP speaker when no
>explicit policy is associated with a BGP peering session."
> 
> Please read/comment/advise before 11/23/2015 - Nov 23, 2015.

I support adoption of this document.

Kind regards,

Job

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

[GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Christopher Morrow]

Howdy Grow folk (again),
Please consider this as the start of a 3wk working group adoption call
for the subject draft who's abstract is:

  "This document defines the default behaviour of a BGP speaker when no
   explicit policy is associated with a BGP peering session."

Please read/comment/advise before 11/23/2015 - Nov 23, 2015.

Thanks!
-chris
grow-co-chair

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

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

[Christopher Morrow]

Howdy WG folks,

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."

Please read/comment/advise by:
  11/23/2015 - Nov 23 2015

thanks!
-chris
grow-co-chair

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

Re: [GROW] IETF94 GROW meeting notes

[Christopher Morrow]

On Mon, Nov 2, 2015 at 5:50 PM, Job Snijders  wrote:
> Notes from the IETF94 GROW meeting in Yokohama, Japan.
>
> Chairs: Christopher Morrow & Peter Schoenmaker
> Jabber: Colin Petrie, Notes: Job Snijders



These are uploaded to the tools-site.

thanks!
-chris

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

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Warren Kumari]

On Monday, November 2, 2015, Christopher Morrow <
christopher.mor...@gmail.com> wrote:

> Howdy Grow folk (again),
> Please consider this as the start of a 3wk working group adoption call
> for the subject draft who's abstract is:
>
>   "This document defines the default behaviour of a BGP speaker when no
>explicit policy is associated with a BGP peering session."
>
> Please read/comment/advise before 11/23/2015 - Nov 23, 2015.
>
>

Yah.

This shouldn't be needed... but is.
Support adoption, willing to edit / contribute / review / whatever is
needed.

W



> Thanks!
> -chris
> grow-co-chair
>
> ___
> 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

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Jon Mitchell]

> On Nov 2, 2015, at 4:04 PM, Jeffrey Haas  wrote:
> 
> 
>> On Nov 2, 2015, at 3:57 PM, Christopher Morrow 
>>  wrote:
>> 
>> Please read/comment/advise before 11/23/2015 - Nov 23, 2015.
> 
> I support adopting this draft. 
> 
> I suggest it be considered for BCP status.  Why BCP?

Support, agree on BCP.

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