Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 2 Mar 2008 08:37:41 -0800

Hi Sandra,

I also noted the services of RIPE are currently accessible through
http and not https. That is an issue too.

I have notified RIPE about the same.

Thanks,
Vishwas

On Thu, Feb 28, 2008 at 1:12 PM, Sandra Murphy <[email-masked]> wrote:
>
>
>  On Thu, 28 Feb 2008, Vishwas Manral wrote:
>
>  > Hi Sandra,
>  >
>
> > To further clarify,
>  >>  The only point I want to add to the discussion is because we have to
>  >>  verify the Origin only in the first hop peer, we do not need a global
>  >>  database (as I mentioned we are not saving against malicious attacks
>  >>  in any case).
>  > This would mean for someone who gets the information from RIPE does
>  > not need to necessarily use the mechanism the way it currently stands.
>  >
>
>
>  As long as:
>
>  (a) you were interested in protecting only those prefixes that are managed
>  by RIPE - data in RIPE about other prefixes doesn't fall under the
>  protection of their security model, and the RIPE database does not
>  contain all prefixes,
>
>  and
>
>  (b) you were comfortable with the trust model of RIPE (they authenticate
>  the upload of the data with varying strength of authentication and you
>  must get the data, whose aussurance you can not yourself verify, from them
>  and only them with a protected transport they support).
>
>  As an additional wrinkle, I believe that RIPE does allocate prefixes to
>  LIRs.  I do not know if the LIRs are required to maintain the RIPE
>  security model in their allocations.
>
>  --Sandy
>
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2008 10:04:43 -0500

> http and not https. That is an issue too.

An issue for what or whom? And what do you mean by "the services"?

Joe

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 07:14:13 -0800

Hi Joe,

I was talking about the RIPE whois and other related tools that RIPE
provides, when I looked at the link given below:
http://www.ripe.net/news/study-youtube-hijacking.html

As the tools cannot be accessed using https but using http, the tools
cannot be used in a guaranteed fashion. We cannot build scripts over
the tools and feel the information.

Thanks,
Vishwas

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2008 10:22:39 -0500

> the tools and feel the information.

I had no idea they were available over http. Everybody I know who uses  
them uses whois.

As to "cannot build", that doesn't seem to be an opinion shared by the  
many ISPs who "have built".

Joe

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 07:27:52 -0800

Hi Joe,

>  many ISPs who "have built".
The point I raise is about a guarantee of talking to the right server.
If the tools are already built and are not checking the certificate of
the site they are getting the information from, then that is another
weakness in the system, that is breakable.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 07:36:41 -0800

Hi Joe,

To further explain it. In my view SSL is the right protocol for this
kind of transaction (we could use IPSec with BTNS too though). As the
idea is to get the information from the right server, the client
itself could be any one.

Thanks,
Vishwas

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2008 10:43:21 -0500

> idea is to get the information from the right server, the client

That seems like a feasible band-aid over the deficiencies of the  
existing service, although it's clearly no panacea. It also has the  
practical problem that existing scripts that use whois would need  
modification, although the whois "protocol" and client are so trivial  
that it would presumably be straightforward for someone to implement a  
change to the (say) BSD client to implement an SSL wrapper with server- 
side certificate verification.

Allowing the integrity of the data itself to be trusted (e.g. using  
the resource certification work) seems like a more appropriate  
direction than worrying about the security of data retrieval, though,  
which perhaps explains why SSL-wrapping whois has not already been  
done by anybody.

Joe

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 07:59:39 -0800

Hi Joe,

If you saw the mail exchange between Sandra and I, you will notice she
mentioned the reason they have to go ahead with SIDR even though we
have tools available from RIPE. What I have been trying to do is to
figure out weaknesses. in the current infrastructure to get a secure
behavior. As a first step I found out this weakness and updated RIPE/
Daniel about the same.

As we discussed earlier SIDR does not provide a totally secure
infrastructure. The point here is that SIDR is giving some very basic
improvements in the security, generally in the non-malicious case. The
idea is can we get a similar security with the current infrastructure,
by doing minor improvements. There is a certain cost involved with the
SIDR infrastructure.

I do not think the SSL channel has not been done because it is
unnecessary. I guess there hasn't been an attack on that side of the
infrastructure yet, but these are well known issues/ attacks in other
fields.

Thanks,
Vishwas

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 4 Mar 2008 11:34:18 -0500 (Eastern Standard Time)

> behavior. As a first step I found out this weakness and updated RIPE/

Please keep in mind that RIPE is not the only IRR.  And RIPE can not 
verify authorization for prefixes and ASs outside its range.  So improving 
RIPE does not buy you what you want.

> improvements in the security, generally in the non-malicious case.

Please keep in mind that I have said SIDR does most definitely protect 
against malicious attacks for those attacks it is addressing.

SIDR makes no difference between maliciousness or carelessness in the 
attacks it counters.

There are plenty of malicious and accidental ways to attack routers that 
are not in the realm of what SIDR is considering now.  Maliciousness is 
not the distinguisher here.

To be plain, to say SIDR addresses only non-malicious cases is flat out 
WRONG.  (And sorry for not having pointed that out before, I thought I 
did.)

> The

No, we cannot get similar security with current infrastructure, even with 
MAJOR improvements to the security of the current infrastructure.  The 
structure of the current infrastructure does not permit similar security 
to what the RPKI provides.

Unless, of course, you want to add all RPKI features to the IRR model, so 
that the IRR becomes the same as the RPKI.  Of course, you adopt the cost 
as well.

--Sandy

> infrastructure yet, but these are well known issues/ attacks in other

<snip>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 08:49:41 -0800

Hi Sandra,

You are right RIPE is not the only IRR. The reason I brought up RIPE
is because it was mentioned that RIPE provides more secure services.
If it is a good model, I would wonder why other IRR cannot do the
same.

>  WRONG.  (And sorry for not having pointed that out before, I thought I
Sandra, yes you mentioned it clearly in your mail. Let me put an
analogy for the same and let me know if our differences of opinions
match, We have 4 glasses on a window and one of them has been made
fully bulletproof at a big expense. The point you raise is it protects
when you hit against the glass that has been made bulletproof. The
point I bring out is that if at a cheaper cost we can harden the
glasses it may be a better option. That is what I mean by
non-malicious intent.

I guess that is the difference of opinion we have.

Thanks,
Vishwas

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2008 00:18:58 -0500

> many ISPs who "have built".

http://www.ripe.net/db/support/update-reference-manual.pdf

Read the abstract and you'll find out what is used for security.  Its
a bit old but it works.

The query or update is in the clear (not encrypted) but can be
authenticated with a signature over the contents.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2008 00:34:04 -0500

In message <[email-masked]>
Sandra Murphy writes:
> [---8<---snip---]

Sandy,

Would you please enumerate those things that the IRR model does not
support after reading RFC2725 and RFC2769.

Note that RFC2769 has not been implemented but would provide the
missing functionality (ability to authenticate information held in
other registries).  It also provides efficient replication of
databases so anyone can have a local copy of any database of interest
to improve query time.

I am not advocating going in that direction, simply pointing out that
SIDR to a large extent reinvents the wheel.  If anything I think SIDR
not implementing the full RPSL semantics is deficient.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Mar 2008 22:42:45 -0400

At 12:34 AM -0500 3/6/08, Curtis Villamizar wrote:
>I...

Curtis,

My impression was that 2769 does not address the same set of concerns 
that the RPKI work is addressing.

The RPKI provides a strong, cert-based link between the resource 
allocation hierarchy and signed objects that attest to resource 
holdings. The use of ROAs and analogous signed objects (verifiable 
under the RPKI) enable resource holders to make clearly defined 
assertions about resources, e.g, the authorization of an AS to 
originate a route to a prefix. These assertions can be verified 
without worrying about the integrity of the management of an IRR, 
e.g., the path via which the object was obtained.

2769 seems to focus on authorization to manage objects in the IRR, a 
very important but distinct concern.  The integrity model seems to 
emphasize transitive trust (e.g., tracing data integrity back to an 
authoritative directory), and authorization of manage an object. This 
is different from the use of signed objects that can be verified 
through use of an authoritative PKI. (I note that the term PKI does 
not appear anywhere in the RFC, and the term certificate (or cert) 
appears only a few times. There are references to use of PGP keys for 
authenticating a user who wants to manage objects, but that is a very 
different use of public key crypto.)

It is appropriate to examine the intersection of the IRR/RPSL model 
and the SIDR work to see how the two can fit together, but I disagree 
with the suggestion that SIDR "reinvents the wheel." SIDR adopts a 
different initial focus, i.e., defining a profile for certs that 
represent resource holdings. As we move to introduce additional 
signed objects, e.g. ROAs and BOAs, then  we get closer to some of 
the functionality of RPSL.

Steve

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Mar 2008 15:49:19 -0400

On Thu, Feb 28, 2008 at 01:34:49PM -0500, Sandra Murphy wrote:
> When I say origination of route advertisements, I am not talking about the 
> ORIGIN attribute in the BGP Update.

I'd suggest refering to this as the originating AS.

-- Jeff

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 10 Mar 2008 16:52:41 -0400 (Eastern Daylight Time)

> In message <[email-masked]>

<< snip >>
> not implementing the full RPSL semantics is deficient.

I commented last July on the security model (RPSS) used in RIPE

http://www.ietf.org/mail-archive/web/sidr/current/msg00207.html

To expand a bit.

The model in RPSS has a similar basis as the model used in the RPKI, 
namely that delegation of a prefix requires authority over a covering 
prefix - that comes from the inetnum authorization requirement.  The RPSS 
model also insists that the prefix holder is the one who authorizes 
origination of routes to that prefix.

The RPSS model goes further to insist that authorization to originate 
routes (actually, to create a route object for a prefix) must also be 
granted by the AS mentioned.  In that the authorization model in RPSS is 
different than the RPKI model.

That makes revoking authorization different as well.  To delte a route 
object in RPSS, you need the authorization of both the prefix holder and 
the AS.  (This could cause difficulties if some prefix holder changes 
providers and wishes to remove the route object, if its former provider is 
not interested in OK the route object deletion.)

RFC2769 addresses the problem (I think) of invalidating inetnums that are 
derived from an inetnet that gets deleted.  (If that is what is meant as 
"repeating authorization checks".)  It seems to me that there is no way to 
bound the number of database objects that are potentially effected by one 
object deletion.

But the biggest difference is in the trust model.  RPSS assumes that the 
IRR has a way to authenticate the principles - the maintainers.  A 
particular object might have multiple maintainers (of various types) and 
each can have more than one way to be authenticated.  The maintainers 
authenticate in some way to the IRR and the IRR stores the data.  Those 
referring to the data must have some way to retrieve the data from the IRR 
that is itself secure.

But even with a secure retrieval, the data retrieved carries no hint of 
the authentication with which it was transmitted to the IRR.  You don't 
know which maintainer placed the info there and you don't know what 
authentication mechanism was used in accepting the data.

No one can authenticate the data except the IRR, and no one can know what 
assurance to place in the data, aside from a blind "I trust my IRR".

There are also issues of staleness of data, as there is no mechanism to 
state and enforce a validity period.  (From reports, stale IRR data played 
a part in the spread of bogus info in the Con Ed incident last year.)

An IRR might go to using the strongest authentication possible, and to 
accepting signed data and storing the signature.  And publishing the certs 
it assigned to users.  That would go pretty far to giving the same 
assurance of the RPKI.  But that's kind of what I meant about adopting the 
same mechanisms as the RPKI, and therefore the cost

--Sandy.