Subject: Re: [Crisp] Question on routing policy databases

From: Nagahashi Kengo <[email-masked]>
Date: Tue, 6 Sep 2005 10:52:07 +0100

Hi All,

We are planning to revise the rreg draft 01->02. Thanks to
constructive comments and suggestions in crisp-wg meeting, our
major modifications are including (1)clarify a difference
between EPP and CRISP, and (2)feedback from operators.

In terms of EPP/CRISP discussion,  our focus is CRISP
for IRR, is not EPP for IRR. As Kuniaki pointed out, 
fundamental issue of IRR is mirroring architecture.
Since  current mirroring performs non-realtime mirroring
(NRTM), it requires not only full mesh mirroring of 
all IRRs but also arising an instable propagation issue which 
one IRR does not propagate  routing information
e.g. route object to other IRR, and all this leads inaccurate
information. Our intention is to improve that situation by
introduing rreg. In this view point, EPP seems not to provide
any solutions since current update procedure in IRR does not
affect propagation issue. 

any comments would be appreciated.

cheers.

-kengo

On Tue, 23 Aug 2005 14:45:16 +0900
Kuniaki Kondo <[email-masked]> wrote:

> Hi, All.
> 
> >Briefly put, no one needs an address allocation in an instant (like 
> >within a hour or day).  We can quibble about how well a registrant 
> >may plan ahead, or how much of a supply of space an RIR/NIR/LIR 
> >buffers, but realistically, you will know ahead of time.  On the 
> >other hand, routing problems happen in an instant.
> 
> Yes, routing problems happen in an instant. And when routing problems
> happen, operators must solve the problems as soon as possible: 
> for example, operators immediately derive route filters from IRRs
> and set them on their border routers. If ISP-A does not register
> their route information into some IRR, other ISPs ignore the ISP-A's
> routes because the route filters derived from IRRs do not contain
> the ISP-A's route information: this means ISP-A loses reachability.
> 
> Registering routing information to IRR and keeping IRR up-to-date
> is quite important, but it does not solve all the problems.
> 
> The most important problem is the overall architecture of IRRs.
> In some cases, registering a route information to an IRR cannot be
> referred from another IRR. I believe this problem MUST be solved,
> and CRISP and EPP can help to solve the problem.
> 
> Here I describe the reason and real story:
> 
> Currently, IRR has NRTM mechanism referring to mutual information.
> However, in the NRTM mechanism, IRRs must be configured with FULL MESH
> mirroring, and each IRR must have copies of all the other IRRs' data.
> I believe that this mechanism does not scale. Furthermore, NRTM does
> not support propagating IRR information. That is, IRR must have 
> complete full mesh mirroring. Actually, I found some case in Japan
> what ISP-A registered AS information to IRR-A. After a while, IRR-A 
> deleted ISP-A's AS information. Then, ISP-A lost reachability 
> to anywhere. ISP-A try to register ISP-A's information to IRR-B,
> but the problem was not solved. Because, one ISP refers to IRR-C
> to make route filter, and IRR-C mirror with IRR-A, and IRR-C does
> not mirror with IRR-B. This problem can be avoided if IRRs have
> hierarchical topology and information transport mechanism between IRRs.
> 
> I believe that CRISP is a good solution to solve these problems.
> 
> --
> kuniaki,
> Regards.
> 
> >
> >My presumption is that the speed of the provisioning process 
> >determines how much you need to automate the interface.  Provisioning 
> >numbers takes more time than names, more time than routes.
> >-- 
> >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >Edward Lewis                                                +1-571-434-5468
> >NeuStar
> >
> >If you knew what I was thinking, you'd understand what I was saying.
> >
> >_______________________________________________
> >Crisp mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/crisp
> >
> 
> 
> _______________________________________________
> Crisp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/crisp
> 

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: William Leibzon <[email-masked]>
Date: Tue, 6 Sep 2005 16:20:22 -0700 (PDT)

On Tue, 6 Sep 2005, Nagahashi Kengo wrote:

> information.

But mirrorring also has its advantages - you do not relay on remote
sever that maybe temporarily down (or not accessible until you
actually setup proper routing to them for which you might need
to consult the RR - you see the loop, right :) but consult local RR 
servers of your ISP's RR that you know how to get to and trust.

My preference would be to allow mirroring but also require link
(CRISP link, i.e. request redirect with a "bag") to where information
about where data came from. The client would then choose what to
use and toolmakers can do it so that redirect is followed wheneber 
possible but if its not then mirror data is used.

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Sep 2005 14:30:29 +0700

>On Tue, 6 Sep 2005, Nagahashi Kengo wrote:
...
>But mirroring also has its advantages - you do not relay on remote
>to consult the RR - you see the loop, right :) but consult local
>RR servers of your ISP's RR that you know how to get to and trust.

There is a generic goal of safety systems of having needed 
information available upon demand.  Presuming that IRRs are routing 
"safety" components, what this means is that during a time when 
routers need to validate updates they ought to be able to get the 
security data (evidence) they need.  Relying on referrals from one 
IRR to another runs counter to this goal simply because it "involves 
more moving parts."  The other IRR must be reachable, it must be up, 
etc.

E.g., a few years ago I worked on a security project that pulled X509 
certificates from DNS to validate a defense against a DOS attack. 
The problem was that the DOS attack prevented accessing the DNS.  So, 
we built a parallel network, one for the DOS attack and another for 
DNS lookups.  (It was a prototype, so we could do that.)

NTRM might be an important ingredient, even if there are scaling 
fears.  IRIS isn't a mirroring protocol.  That doesn't mean IRIS 
isn't to be considered, just that perhaps there are more pieces of 
the puzzle.

---

From: Nagahashi Kengo <[email-masked]>
Date: Wed, 7 Sep 2005 09:26:48 +0100

Hi,

First of all,we authors would appreciate for your constructive comments.

As far as my understanding, a proposal like DNS based NLRI origin AS 
verification does not make a standadrd is the exact reason what Edward
addressed. In that context, requrements for routing database is rather 
different with other databases such as address or domain. 

One of our intentions to introduce rreg is to improve consistency in IRR.
Though mirroring offers several advantages such as keeping as
local storage, however, it obviously lacks consistency. 

In that manner, a suggestion "to allow mirroring but also require link
by CRISP" seems to be realistic. Any comments would be appreciate.

thanks.

-kengo

On Wed, 7 Sep 2005 14:30:29 +0700

-- 
Kengo Nagahashi,Ph.D. 
University of Cambridge Computer Laboratory  
William Gates Building 15 JJ Thomson Avenue  
Cambridge CB3 0FD UK  
Tel: +44 (0)1223 763651  | Fax: +44 (0)1223 334678  
http://www.nagahashi.org/kengo/

---

From: Kuniaki Kondo <[email-masked]>
Date: Wed, 7 Sep 2005 17:43:09 +0900

Hi, All

>by CRISP" seems to be realistic. Any comments would be appreciate.

 I am also realistic. However, if a data by mirroring
 and a data by getting crisp are different, which data are correct?
 It is very rare case.
 Normally, the data by getting crisp is managed by the data owner,
 and the data by mirroring is not managed by the data owner, because
 mirrored data is copied to other places.  If it is correct,
 it is fine to choice the data by getting crisp. But, when crisp link
 is down, IRR server can not verify to use both data.

 If the IRR server possibly response illegal data, it should response
 error.

>> isn't to be considered, just that perhaps there are more pieces of 

Kuniaki KONDO - Intec NetCore, Inc.
[email-masked] - http://inetcore.com/
NATS Project - http://www.nats-project.org/
イベントML - http://www.bugest.net/event-ml.html

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Sep 2005 16:14:18 +0700

>  and a data by getting crisp are different, which data are correct?

I didn't intend to raise this issue, a discussion of this is 
off-topic for the CRISP WG.

What I meant to do is raise the point that perhaps a data mirroring 
protocol is needed in addition to EPP and IRIS.

>  is down, IRR server can not verify to use both data.

Yes, there are such issues.  But not for the CRISP WG mail list.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: William Leibzon <[email-masked]>
Date: Wed, 7 Sep 2005 05:12:29 -0700 (PDT)

>>  and a data by getting crisp are different, which data are correct?

In my opinion the data at the origin pointed by CRISP link takes
precedence over any mirror data. This is kind of like that mirror
is a heresy and heresy is not considered reliable in legal terms but
in practice we all are used to listening to others and reading media 
which publish heresy all the time and we find this more convenient
then asking the original story-teller.

For me what this all means as far as IRR and CRISP is that tools
should be built to get entire needed data from its preferable IRR,
then look at the links and follow them but if answers are not received 
within short time-out period use mirror data. Another possibility is
to use only mirror data when its necessary to bring up network and
setup filtering rules for first time but once its done and when task is
to update the rules, then attempt to get data from IRRs by CRISP link.

>>  It is very rare case.
>
> I didn't intend to raise this issue, a discussion of this is off-topic for 
> the CRISP WG.
>
> What I meant to do is raise the point that perhaps a data mirroring protocol 
> is needed in addition to EPP and IRIS.

I think it is indeed needed and I'm surprised that RIPE or APNIC
did not bring it up so far because RIPE server is based on the mirroring 
concept and in APNIC region the country IRs (NIRs or CIRs - I keep 
forgetting what they call it) export (mirror) their data to APNIC.
The same mirroring functionality is even more heavily used for IRR.

> Yes, there are such issues.  But not for the CRISP WG mail list.

I believe its appropriate to reserve judgment as to what is and is
not off-topic on this mail list to the WG Chairs. But I'll give my
personal opinion on this subject and its is different then Ed's.

First of all, I agree that the actual work would not be on-topic as
CRISP item based on current chapter, but neither really is CRISP IRR 
draft. However as has been agreed at the meeting in Paris the draft 
should be discussed further at the CRISP WG mail list and is not
off-topic here. Further as the draft is being considered for official
inclusion into CRISP, we had also been asked to discuss issues with
this work in the context as to what changes would be needed to CRISP 
Charter to complete this new work item.

In the content of above I conclude that discussions of the IRR issues
and needed work (be it something that is EPP related or mirroring) are
on-topic to this list as long as we're considering IRR draft. Plus
as to the mirroring if we decide that new protocol is needed we may
need to discuss who will develop this protocol and we may actually
decide to work on it as part of CRISP as such discussions related to
this area are appropriate as discussions that may lead to future
changes to CRISP Charter (which will be needed for IRR anyway).

---
William Leibzon

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Sep 2005 08:08:31 -0400

> protocol is needed in addition to EPP and IRIS.

I know I will probably get punched for saying this by one of my co- 
authors, but take a look at Section 5 of draft-hardie-ecrit- 
iris-02.txt.  It's not called mirroring, but the concept is the  
similar...

-andy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Sep 2005 07:54:52 +0700

At 8:08 -0400 9/7/05, Andrew Newton wrote:
>>  What I meant to do is raise the point that perhaps a data 
>>mirroring protocol is needed in addition to EPP and IRIS.
>
>I know I will probably get punched for saying this by one of my co-authors,
>but take a look at Section 5 of draft-hardie-ecrit-iris-02.txt.  It's not
>called mirroring, but the concept is the similar...

That coincides with what I am thinking - I think the intro to 5 is dead-on.

I'm just surprised to see an extension to IRIS to do mirroring.  Not 
alarmed, just surprised.  It's worth looking in to (before me making 
any other comments.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Kuniaki Kondo <[email-masked]>
Date: Fri, 9 Sep 2005 12:10:21 +0900

>to update the rules, then attempt to get data from IRRs by CRISP link.

 In first time, I think same answer, too. But if data by mirroring included
 some missed data, IRR data user make route filters using missed data.
 It means that an operated network by the IRR data user injects incorrect
 route or AS filters, in lower case, the network traffic stop.
 (It is my real experience...)

 So, I think that IRRs don't have both mirroring and crisp link so, 
 IRRs should have redundant crisp links.

>The same mirroring functionality is even more heavily used for IRR.

 JPNIC IRR planing team who are considering what IRR service for 
 JP area IRR user is good and useful started IRR service for JPNIC
 member. Many Japanese IRR user registered data to RADB. But, 
 some network registered their data to APNIC IRR or Japanese local
 IRRs. In this case, Japanese IRR user can not get entire IRR data,
 because IRR data dispersed.

 Fortunately, APNIC collect many many IRR data using mirroring and
 NRTM system from over 30 or 40 IRR servers including RADB and RIPE.
 We decided to use APNIC IRR to get IRR data for mirroring with 
 our IRR. (Some good answer is that IRR user directory access to 
 APNIC IRR, but it is not scale. IRR user access to many hundreds times
 to make filters. At that time, APNIC IRR operator probably stop the
 access why it is DoS attacks.)

 However, some IRRs does not permit to propagate their IRR data using 
 APNIC IRR server. If we collect entire IRR data, we also mirror with
 many IRR serves.

 Another hands, We have our origin IRR data (source: JPIRR).
 In this situation, there are problems.
 Currently, our IRR data mirror with APNIC and RADB  using mirroring.
 (RADB get our data through APNIC IRR. JPIRR -mirror-> APNIC -mirror-> RADB)
 But, other IRRs did not refer JPIRR.

 As I explained, Mirroring method is used in everywhere. 
 And mirroring method reached limit, I think.

---
Thank you.