Subject: Re: [OPSEC] [Sidr] 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
>
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

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: Roland Dobbins <[email-masked]>
Date: Tue, 4 Mar 2008 22:18:42 +0700

[removed cross-post to sidr list; folks, cross-posting is considered  
poor form and is a breach of netiquette, please don't do it]

On Mar 4, 2008, at 10:14 PM, Vishwas Manral wrote:

> the tools cannot be used in a guaranteed fashion.

How does the use of SSL 'guarantee' anything except that you're  
talking to what you think you're talking to, heh?  What kind of  
'guarantee' is that, since it doesn't ensure the integrity nor the  
correctness of the data?

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // +66.83.266.6344 mobile

      If you don't know what to do, it's harder to do it.

                    -- Malcolm Forbes

---

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: Roland Dobbins <[email-masked]>
Date: Tue, 4 Mar 2008 22:33:33 +0700

> The point I raise is about a guarantee of talking to the right server.

Since this doesn't guarantee the correctness/validity of the data,  
doesn't that mean that the use of certificates is a waste of time,  
anyways?

Or are you *now* stating that we shouldn't make the perfect the enemy  
of the merely good?

;>

As Joe indicates, most tools access that data via whois, anyways, FYI.

                    -- Malcolm Forbes

---

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

Hi Roland,

>  talking to what you think you're talking to, heh?
You may be missing the point here. There are two phases of getting the
information from the RIPE servers. One is whether we are talking to
the right server, second is whether RIPE is getting the right
information. Both are just as critical.

If we are to make decisions in our network based on information from
RIPE (tools that have been built), we have to make sure we are
actually getting the information from RIPE and not some other site. It
is the same reason all your banking transactions are done over https.

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: Roland Dobbins <[email-masked]>
Date: Tue, 4 Mar 2008 22:43:34 +0700

On Mar 4, 2008, at 10:34 PM, Vishwas Manral wrote:

> actually getting the information from RIPE and not some other site.

I would submit to you that if your network is so compromised that you  
can't be sure you're talking to RIPE, you've problems mere technology  
can't solve, anyways.  I would also submit that if the RIPE netblocks  
were hijacked, that folks would notice immediately.

You seem to have a very low opinion of the level of security-related  
clue of the operational community, or at least the people on this  
list; why is that?  Since RIPE data aren't available today via HTTPS,  
and since the policies derived from the RIPE data seem to work, and  
since the Internet in general seems to work, you might wish to  
reconsider lecturing those with actual operational experience about  
the basic principles of information security which they already  
understand better than most, and instead spend some time thinking  
about (and perhaps asking about, rather than making flat, uninformed  
statements about) why it is that folks haven't done various things  
which you seem to think are so blindingly obvious.

To be clear, everyone here understand what HTTPS is and what certs are  
and what they're useful for and what they don't solve.  We also  
understand all the rest of the basics (as well as quite advanced  
concepts) of information security.  We don't need a primer, thanks  
just the same.

                    -- Malcolm Forbes

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 4 Mar 2008 22:46:00 +0700

[continuing to remove cross-posts to sidr]

On Mar 4, 2008, at 10:36 PM, Vishwas Manral wrote:

> In my view SSL is the right protocol for this
> kind of transaction

Correct, that's *your view*.  If you feel very strongly about it, you  
may wish to query the RIPE folks as to why they aren't using it, and  
perhaps volunteer your services to help them implement it, if they  
deem it a useful idea, rather than explaining HTTPS concepts to folks  
who're already quite aware of how HTTPS works.

                    -- Malcolm Forbes

---

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: Roland Dobbins <[email-masked]>
Date: Tue, 4 Mar 2008 23:20:34 +0700

[continuing to remove netiquette-breaching cross-post to the sidr list]

On Mar 4, 2008, at 10:59 PM, Vishwas Manral wrote:

> these are well known issues/ attacks in other fields.

They're well-known in this field, too.

                    -- Malcolm Forbes

---

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.

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

On Tue, Mar 4, 2008 at 8:34 AM, Sandra Murphy <[email-masked]> wrote:
>
>
>  On Tue, 4 Mar 2008, Vishwas Manral wrote:
>
>  > Hi Joe,
>  >
>  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
>
>
>  >
>  <snip>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 4 Mar 2008 10:20:21 -0800

Hi Roland,

Thanks for bringing forward the breach to keep us on track and
continuously reminding us.

It seems the reason every one has been cross-posting(including the
chairs of both the groups) is because the same may be of interest to
the two mailing lists.

Thanks again,
Vishwas

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2008 19:11:29 -0500

> information. Both are just as critical.

In practice, if I can verify that the data is accurate, I don't care  
where I got it from.

I'm not sure where this discussion is going, except round in circles  
(I've made the point above before, I think).

Joe

---

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

--Sandy

<snip>

---

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

In message <[email-masked]>
Joe Abley writes:
> Sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

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.