Subject: Re: [GROW] Fwd: New Version Notification for draft-gersch-grow-revdns-bgp-00.txt

From: Christopher Morrow <[email-masked]>
Date: Mon, 5 Mar 2012 16:21:52 -0500

It would be helpful to the chairs (at least) to get a sense of the
'room' (list) on this topic, it seems that the focus is really on a
dnsops sort of paper, though interaction could be had in the routing
space as well (or that's an intent of the draft's work).

It's not clear that GROW is the place for this work, but keeping folks
informed isn't a bad plan either (I think).

-chris
(co-chair)

On Tue, Feb 28, 2012 at 3:58 PM, Joseph Gersch <[email-masked]> wrote:
> All,
>   we have submitted a new draft that we would like to present at the Paris
> IETF meeting.
> Please take the time to send any comments and suggestions regarding this
> idea on using records in  the reverse DNS to help secure BGP route origins.
>
> Best regards,
>    - Joe Gersch, Dan Massey, Eric Osterweil and Lixia Zhang
>
> Begin forwarded message:
>
> From: [email-masked]
> Subject: New Version Notification for draft-gersch-grow-revdns-bgp-00.txt
> Date: February 28, 2012 1:51:59 PM MST
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
>
> A new version of I-D, draft-gersch-grow-revdns-bgp-00.txt has been
> successfully submitted by Joe Gersch and posted to the IETF repository.
>
> Filename: draft-gersch-grow-revdns-bgp
> Revision: 00
> Title: DNS Resource Records for BGP Routing Data
> Creation date: 2012-02-29
> WG ID: Individual Submission
> Number of pages: 22
>
> Abstract:
>   This draft proposes the creation of two DNS record types for storing
>   BGP routing information in the reverse DNS.  The RLOCK record allows
>   prefix owners to indicate whether the DNS is being used to publish
>   routing data.  The SRO record allows operators to indicate whether an
>   IPv4 or IPv6 prefix ought to appear in global routing tables and
>   identifies authorized origin Autonomous System Number(s) for that
>   prefix.  The published data can be used in a variety of contexts and
>   can be extended to include additional information.  This work is part
>   of an on-going effort and is accessible in an active testbed.
>
>
>
>
> The IETF Secretariat
>
>
> Joseph Gersch
> Chief Operating Officer
> Secure64 Software Corporation
>
>
>
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Mar 2012 15:40:51 -0800

Hi Chris,

I think GROW would be the place to discuss this work.

Yes, it uses DNS and proposes two new RRs ( which will still want some
review from DNS folk for the DNS implementation side ) but I feel it has a
more directed focus into global routing ops with a security lens. With the
absence of a generic 'routing security' WG and the very tight focus of SIDR
on one particular technology by charter, GROW appears to me to be the most
sane choice.

Cheers
Terry

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 5 Mar 2012 20:12:23 -0500

Chris,

This draft appears to be operating in the same area as the origin authentication work that is currently progressing in SIDR. Shouldn't all of that work be in one place?

My guess is that it belongs in SIDR.

                                                 Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Monday, March 05, 2012 4:22 PM
> To: Joseph Gersch
> Cc: [email-masked]
> Subject: Re: [GROW] Fwd: New Version Notification for draft-gersch-
> grow-revdns-bgp-00.txt
> 
> >   we have submitted a new draft that we would like to present at the
> > Paris IETF meeting.
> > Please take the time to send any comments and suggestions regarding
> > this idea on using records in  the reverse DNS to help secure BGP
> route origins.
> >
> > Best regards,
> > Title: DNS Resource Records for BGP Routing Data Creation date:
> > 2012-02-29 WG ID: Individual Submission Number of pages: 22
> >
> > Abstract:

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 5 Mar 2012 20:31:22 -0500

> My guess is that it belongs in SIDR.

also was my guess, just looking for consensus on that I believe I was.

-chris

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Mar 2012 17:38:27 -0800

>From my reading of the SIDR charter:

" Building upon the already completed and implemented framework:

* Resource Public Key Infrastructure (RPKI)
* Distribution of RPKI data to routing devices and its use in
operational networks
* Document the use of certification objects within the secure
routing architecture "

I didn't see any RPKI use mentioned in revdns-bgp.

So my guess is that if you went to present this at SIDR, most SIDR folk
would say "it doesn't use RPKI" this is not the place. Irrespective of how
flexible the chairs implement the charter under the allowances of the
responsible AD.

Cheers.
T.

On 6/03/12 11:31 AM, "Christopher Morrow" <[email-masked]>
wrote:

>> This draft appears to be operating in the same area as the origin
>> authentication work that is currently progressing in SIDR. Shouldn't all of
>> that work be in one place?
>>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 5 Mar 2012 20:48:15 -0500

Is it attempting to solve a problem which is also being worked in SIDR? 

                                                Ron

> From: Terry Manderson [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 8:38 PM
> To: Christopher Morrow; Ronald Bonica
> Cc: [email-masked]
> * Document the use of certification objects within the secure routing
> architecture "
> 
> would say "it doesn't use RPKI" this is not the place. Irrespective of
> how flexible the chairs implement the charter under the allowances of
> the responsible AD.
> 
> Cheers.
> T.
> 
> 
> >> authentication work that is currently progressing in SIDR. Shouldn't
> >> all of that work be in one place?
> >>
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of Christopher Morrow
> >>> It's not clear that GROW is the place for this work, but keeping
> >>> folks informed isn't a bad plan either (I think).
> >>>
> >>> -chris
> >>> (co-chair)
> >>>
> >>>>   we have submitted a new draft that we would like to present at
> >>>> the Paris IETF meeting.

---

From: Tony Li <[email-masked]>
Date: Mon, 5 Mar 2012 17:59:42 -0800

Not to mention we rejected this idea long ago, in favor of working on SIDR.

It's dead, Jim.

Tony

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Mar 2012 18:08:30 -0800

from the draft in question:

" We limit the scope of this internet draft to the prevention of origin
   and sub-prefix hijacks -- a capability that can be implemented and
   deployed in a reasonable time frame."

I think SIDR has completed its work on this item.

This looks to me like a fresh set of eyes on the problem.

I'd be willing, if there is time on the grow agenda, to listen to what the
authors are proposing and then reflect on the GROW v SIDR question.

You may be right - it may be a SIDR item. But given the SIDR space right now
seems to be focused on the interaction with and between routers I'm not sure
presenting it in SIDR will be be good for either SIDR or the Authors.
 .. just saying is all..

Cheers
Terry

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 06 Mar 2012 03:19:53 +0100

Hi Tony,

> Not to mention we rejected this idea long ago, in favor of working on SIDR.

Would you happen to have a pointer to the list discussions on this ? Did 
that included DNSSEC at that time ?

I agree with Terry here that this is just a fresh look at the problem 
space. If SIDR is mandated by the charter to be based on RPKI this 
clearly does not belong there. It seems like this is a new operational 
tool which GROW WG may be a good fit for.

I would support to get this presented in GROW if there is room in the 
agenda.

Rgs,
R.

---

From: Tony Li <[email-masked]>
Date: Mon, 5 Mar 2012 18:28:41 -0800

Hi Robert,

> Would you happen to have a pointer to the list discussions on this ? Did that included DNSSEC at that time ?

This was an NDSS discussion at the time.  Same community tho.  Yes, it included DNSSEC.

http://www.isoc.org/isoc/conferences/ndss/99/proceedings/slides/li.pdf

Tony

---

From: Arturo Servin <[email-masked]>
Date: Tue, 6 Mar 2012 08:49:25 -0200

Chris, Ron

	I do not think that grow is the best place for this work. I agree that SIDR does not consider it in its current charter, but I do not see any other WG where this work should be.

	Perhaps, trying to re-charter SIDR to inclue this work? Yes, it may be hard but I think we need to work on this in SIDR to have complementary and aligned solutions with the current work on RPKI, origin-validation and BGPSEC.

Regards,
/as

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 7 Mar 2012 19:52:11 +0700

> Not to mention we rejected this idea long ago, in favor of working on SIDR.

FWIW, I view using the DNS for this sort of thing as both a) essentially, a recursive dependency and b) a layering violation, and it should be avoided on either one of those grounds.

---

From: Joseph Gersch <[email-masked]>
Date: Wed, 14 Mar 2012 10:13:59 -0600

This thread is raising two questions:
   1) should the discussion be in GROW or SIDR?
   2) hasn't this idea been discussed before

--- Regarding the location for the draft,  the group presented arguments on both sides.    We believe that GROW is the proper place to lead the discussion.  However we have been invited to give a summary presentation at SIDR to ensure that all interested parties are aware of this proposal.  However, SIDR limits their scope to:    

> * Is an Autonomous System (AS) authorized to originate an IP prefix 
> * Is the AS-Path represented in the route the same as the path through 
> which the NLRI traveled 

Neither of these really fit our draft well.   You cannot use our approach to see all the prefixes that are authorized to originate from a given AS.   Instead of looking at prefix ranges or an AS,  this approach starts from a specific prefix and asks to identify its origin AS.   This is similar,  but not identical to what SIDR seeks to do. 

The second SIDR objective does not fit our work at all.    We do not seek to validate a complete many hop path.    In this sense, we don't fit SIDR.    As we mentioned above,  we are interested in getting comments from SIDR,  but we feel GROW is a better fit.    In addition,  we have an operational testbed and are working to get more participants in operations.   This is something people can participate in now.   So in this sense,  we were shooting for something we view as more of a routing operation issue and hence GROW.  

This proposal also impacts the DNSOP and DNSEXT groups.  We have asked people on those mailing lists for comments, and a presentation will be made at DNSOP as well.

--- Regarding the "already discussed issue":
   This earlier proposal was the T Bates / R Bush draft from 1998.  A lot of progress has taken place during the last 14 years.  The root zone and in-addr.arpa are signed with DNSSEC.   A naming convention for CIDR addresses in the reverse DNS is being proposed at DNSOP.   These new record types enable some interesting capabilities that are
worth discussing at GROW.  

- Joe Gersch and Dan Massey

Joseph Gersch
Chief Operating Officer

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Mar 2012 18:48:19 -0600

Joseph,

> Neither of these really fit our draft well.   You cannot use our approach to see all the prefixes that are authorized to originate from a given AS.   Instead of looking at prefix ranges or an AS,…

	Validating a prefix using the origin ASN looks a lot to RPKI-Origin Validation.

> - Joe Gersch and Dan Massey

	As I mentioned before, I do not think this work belongs to GROW. I would rather prefer to see it in SIDR as a WG item and to be discussed in parallel here and DNSOP, but not the other way.

	In the end if your approach is to secure bgp, then secure IDR, then SIDR. 

	Also, from SIDR charter I read:

"The two vulnerabilities that will be
  addressed are:

"

	Unless I understood wrongly your draft, I do not see why it does not fit SIDR's charter.

Regards,
.as