I'm studying for OCI certs now - interested in what you used and how did it
go?
I'm also interested in a general way in how much OCI is out there in the
world. It still feels very raw, to us.
thanks!
On Thu, Apr 9, 2020 at 1:40 PM Michael Bullut via NANOG
wrote:
> Greetings Team,
>
> Are there
Greetings Team,
Are there any Oracle Certified Professionals in the group? Currently, I am
undertaking several Oracle certifications during this month and would to
inquire which materials did you use to prepare for the aforementioned?
Warm regards,
Michael Bullut.
---
*Cell:*
*+254 723 393 114
I am not a lawyer, and this is not legal advice, but...
General rule is to always notify the credit card companies, and to notify
legal. One/both/neither may advice law enforcement activity. In either
case, your PCI-required Incident response plan is required to do certain
isolation steps explicit
What advice does your QSA have regarding writing the policy?
There are generic templates available to write your company security policy.
That policy doesn’t necessarily constitute legal definitions or requirements
for any sort of breach, which may vary by locale and provider. I’m assuming
EDUs
Adding to what Rich said, it's very easy for advice on this to cross into
advice on legal matters.
It's also usually very illegal for non-attorneys or non-licensed attorneys
to offer advice on legal matters.
I recommend finding a lawyer with expertise in this area and who has
specific knowledge o
On Wed, Jan 11, 2017 at 09:37:19AM -0500, David H wrote:
> Anyone have pointers/advice on what you came up with for a reasonable
> definition of events that warrant involving law enforcement, and then what
> agency/agencies would be contacted?
This question is best answered by an attorney with e
Hi all, I figure there's probably some folks on the list that have hands in
environments that touch credit cards. Unlike HIPAA compliance, or even
social security numbers, PCI is very ambiguous about what must occur if a
network/systems breach occurs that exposes credit card data. PCI, and its
au
On Mon, Jun 8, 2015 at 4:31 AM, Tony Hain wrote:
> Randy Bush wrote:
>
>> but you can't move packets on pieces of paper.
>
> Or can you? RFC's 6214 2549 1149
But how many avian carriers would you need to move
the packets current pushed around per second, and
how many Mercedes' would have t
On Sun, Jun 7, 2015 at 11:31 PM, Tony Hain wrote:
> Randy Bush wrote:
>> but you can't move packets on pieces of paper.
> Or can you? RFC's 6214 2549 1149
Sure, but rfc1149 needs some work before it could be a viable way of
moving packets. For example: the rfc calls for printing a diagram on
Randy Bush wrote:
> but you can't move packets on pieces of paper.
Or can you? RFC's 6214 2549 1149
;)
On 06/07/2015 09:28 AM, Randy Bush wrote:
i assume, but have zero actual knowledge/experience, that certification
courses/programs actually cover all the corners and minutiae of a subject
such as is-is. so you come out knowing all the options and details, 42%
of which you will use; or maybe 24
On Sun, Jun 7, 2015 at 11:28 AM, Randy Bush wrote:
> i assume, but have zero actual knowledge/experience, that certification
> courses/programs actually cover all the corners and minutiae of a subject
> such as is-is. so you come out knowing all the options and details, 42%
> of wh
i assume, but have zero actual knowledge/experience, that certification
courses/programs actually cover all the corners and minutiae of a subject
such as is-is. so you come out knowing all the options and details, 42%
of which you will use; or maybe 24% if you are parsimonious.
while i no longer
On Fri, Nov 15, 2013 at 4:16 PM, David Temkin wrote:
> I am proud to announce that the final versions of the Data Center and IXP
> standards have been completed by their respective working groups and have
> been published.
>
> Data Center: http://goo.gl/s4cGBp
>
> IXP: http://goo.gl/O5I1my
>
> Ma
I am proud to announce that the final versions of the Data Center and IXP
standards have been completed by their respective working groups and have
been published.
Data Center: http://goo.gl/s4cGBp
IXP: http://goo.gl/O5I1my
Martin Hannigan will follow up shortly with scheduled dates for acceptin
Under the NRO flag, we have just released a short video about Resource
Certification, giving a high-level explanation of what it is and why it is
important for your organisation:
http://youtu.be/rH3CPosGNjY
I hope to release another video going into more detail, outlining what it means
On 31 Jan 2011, at 04:25, Paul Vixie wrote:
> the reasoning you're describing is what we had in mind when we built DLV
> as an early deployment aid for DNSSEC. we had to "break stiction" where
> if there were no validators there would be incentive to sign, and if
> there were no signatures there
be made on some other basis.
> Practically, in the real world, why would anyone invest time and
> effort in altering their current BGP decision making process to
> accommodate for resource certification if the technology is on
> nobody's radar, it's hard to get your feet wet an
On Sun, Jan 30, 2011 at 12:40 PM, Owen DeLong wrote:
> Because they publish data you have signed. They don't have the ability
> to modify the data and then sign that modification as if they were you if
> they aren't holding the private key. If they are holding the private key,
> then, you have, in
In message <4d457f0e.7070...@consolejunkie.net>, Leen Besselink writes:
> Hello Carlos,
>
> On 01/30/2011 02:57 PM, Carlos Martinez-Cagnazzo wrote:
> > What I just don´t get if, we as a society, have created institutions
> > we trust with our *money* (AKA banks), why there can´t be institutions
>
Hey!
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> Because they publish data you have signed. They don't have the ability
> to modify the data and then sign that modification as if they were you if
> they aren't holding the private key. If they are holding the private key,
> then, you ha
On Jan 30, 2011, at 8:28 AM, sth...@nethelp.no wrote:
>>> - Hosted solutions offer a low barrier entry to smaller organizations
>>> who simply cannot develop their own PKI infrastructure. This is the
>>> case where they also lack the organizational skills to properly manage
>>> the keys themselve
> > - Hosted solutions offer a low barrier entry to smaller organizations
> > who simply cannot develop their own PKI infrastructure. This is the
> > case where they also lack the organizational skills to properly manage
> > the keys themselves, so, in most cases at least, they are *better off*
> >
I see also that many concerns expressed here are extensions of the
perceived failures of the whole CA business. I agree that the whole
model of CAs has largely failed. Not only there are too many of them,
but the fact that they try to operate as for-profits makes them
vulnerable to all the pressure
> >There's a big difference. If a bank screws up and loses $5,000 of my
money, I
> > can (at least potentially) sue them and recover $5,000 which is pretty much
> > identical to the $5,000 I lost. If a key escrow company loses my private
> > key,
> > getting back an identical private key is exac
hi alex,
just to be clear
i think your web-based system is a good thing. 97.3% of your members do
not want to go through the effort of installing certifying software and
doing up/down with you. i am not fond of you holding folk's private
keys, but that's what they get for laziness. of course y
On Sun, 30 Jan 2011 11:57:57 -0200, Carlos Martinez-Cagnazzo said:
> What I just don't get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can't be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probably "
e here or in twitter, sorry if I am duplicating):
>>>
>>> http://bgpmon.net/blog/?p=414
>>>
>>>
>>> Best regards,
>>> -as
>>>
>>>
>>>
>>> On 29 Jan 2011, at 13:26, Alex Band wrote:
>>>
>>
Hello Carlos,
On 01/30/2011 02:57 PM, Carlos Martinez-Cagnazzo wrote:
> What I just don´t get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can´t be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probab
On Jan 30, 2011, at 5:57 AM, Carlos Martinez-Cagnazzo wrote:
> What I just don´t get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can´t be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probably "cryp
t;
>>
>> On 29 Jan 2011, at 13:26, Alex Band wrote:
>>
>>> John,
>>>
>>> Thanks for the update. With regards to offering a hosted solution, as you
>>> know that is the only thing the RIPE NCC currently offers. We're developing
>>> su
he last
> month if there were only 5 certified prefixes?
>
> In my opinion, the widespread availability of signed prefixes and mature
> validation methods is key to the global success of resource certification. I
> agree that small differences in the size of the set of signed
widespread availability of signed prefixes and mature
validation methods is key to the global success of resource certification. I
agree that small differences in the size of the set of signed routes don't
matter on a (relatively) short term, but the reality is that the difference
wou
hanks for the update. With regards to offering a hosted solution, as you
>> know that is the only thing the RIPE NCC currently offers. We're developing
>> support for the up/down protocol as I write this.
>>
>> To give you some perspective, one month after launchin
> From: Alex Band
> Date: Sat, 29 Jan 2011 16:26:55 +0100
>
> ... So the question is, if the RIPE NCC would have required everyone
> to run their own certification setup using the open source tool-sets
> Randy mentions, would there be this much certified address space now?
hing the RIPE NCC currently offers. We're developing
> support for the up/down protocol as I write this.
>
> To give you some perspective, one month after launching the hosted RIPE NCC
> Resource Certification service, 216 LIRs are using it in the RIPE Region and
> created 169 R
service. So the question is, if the RIPE NCC
> would have required everyone to run their own certification setup using the
> open source tool-sets Randy mentions, would there be this much certified
> address space now?
For many organizations, a hosted service offers the convenience that w
ource Certification service, 216 LIRs are using it in the RIPE Region and
created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and
7274499 /48 IPv6 prefixes now have a valid ROA associated with them.
I realize a hosted solution is not ideal, we're very open about that. But
[moderation seems slow; resending from subscribed address instead]
On Mon, 24 Jan 2011, Danny McPherson wrote:
I suspect I've sufficiently chummed the waters, I'll kick back and absorb
all the reasons this is a whack idea :)
Short summary: it's not entirely whack, but no one has yet put forwa
> Why does this stop the whole thing short?
the devil is in the details and the trust. i am desperately open to
other approaches. but work it out at the detailed level, not just a
troll on nanog. i anxiously await your and danny's draft.
randy
On 1/27/2011 7:51 PM, Osterweil, Eric wrote:
I think the bottom line is that this infrastructure will allow a security
solution to reach deployment_much_ sooner than a green-field design.
Errr, yeah. See IPv6 deployment.
Jack
On 1/25/11 7:04 AM, "Roland Dobbins" wrote:
>
>
> On Jan 25, 2011, at 9:52 PM, Joe Abley wrote:
>
>> If the DNS was as unreliable as those words suggested, nobody would use it.
>
> I see evidence of this unreliability every day, so I must respectfully
> disagree.
>
> ;>
>
>> The reality
understand something here... Are (for example) the rsync
processes going to use hard coded IPs? Are the SIAs and AIAs referenced by
IP?
>
>> I'm of the belief RPKI should NOT be on the critical path, but instead
>> focus on Internet number resource certification - are you su
On 1/24/2011 8:52 PM, Roland Dobbins wrote:
On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:
thinking of using DNS is tempting
The main arguments I see against it are:
2. The generally creaky, fragile, brittle, non-scalable state of the
overall DNS infrastructure in general.
On Jan 25, 2011, at 9:52 PM, Joe Abley wrote:
> If the DNS was as unreliable as those words suggested, nobody would use it.
I see evidence of this unreliability every day, so I must respectfully disagree.
;>
> The reality is that everybody uses it.
The reality is that they don't really have a
On 2011-01-25, at 01:25, Christopher Morrow wrote:
> On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins wrote:
>
>> 2. The generally creaky, fragile, brittle, non-scalable state of the
>> overall DNS infrastructure in general.
>
> this is getting better, no? I mean for the in-addr and larg
On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins wrote:
>
> On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:
>
>> thinking of using DNS is tempting
>
>
> The main arguments I see against it are:
>
> 1. Circular dependencies.
in the end though... if you depend upon something off-box to
On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:
> thinking of using DNS is tempting
The main arguments I see against it are:
1. Circular dependencies.
2. The generally creaky, fragile, brittle, non-scalable state of the
overall DNS infrastructure in general.
Routing and DN
On Mon, Jan 24, 2011 at 11:27 PM, Steven Bellovin wrote:
>
> On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote:
>> it's not the best example, but I know that at UUNET there were plenty
>> of examples of the in-addr tree not really following the BGP path.
>>
> The other essential point is t
On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote:
> On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley wrote:
>>
>> On 2011-01-24, at 20:24, Danny McPherson wrote:
>>
>>>
>>> Beginning to wonder why, with work like DANE and certificates in DNS
>>> in the IETF, we need an RPKI and new hierarc
On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley wrote:
>
> On 2011-01-24, at 20:24, Danny McPherson wrote:
>
>>
>> Beginning to wonder why, with work like DANE and certificates in DNS
>> in the IETF, we need an RPKI and new hierarchical shared dependency
>> system at all and can't just place ROAs in
On Jan 24, 2011, at 9:21 PM, Richard Barnes wrote:
> The more you have to invent, though, the more this sounds like a
> bike-shed discussion.
> s/DNSSEC/X.509/g
> s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g
The difference is that we don't have an operational RPKI syst
>> the folk who sign dns zones are not even in the same building as the
>> folk who deal with address space.
> I think the idea is to effectuate de-siloing in this space to the
> point that the DNS folks would make the appropriate delegations to the
> addressing folks, who would then proceed to cre
On Jan 25, 2011, at 9:31 AM, Randy Bush wrote:
> the folk who sign dns zones are not even in the same building as the folk who
> deal with address space.
I think the idea is to effectuate de-siloing in this space to the point that
the DNS folks would make the appropriate delegations to the ad
On Jan 25, 2011, at 9:24 AM, Danny McPherson wrote:
> So, are you suggesting the RPKI isn't going to rely on DNS at all?
In terms of organic, real-time route validation performed by routers - which it
is assumed is an ultimate goal of rPKI, at some point in the future - one
should hope this
> Right, I've heard the circular dependency arguments. So, are you
> suggesting the RPKI isn't going to rely on DNS at all?
correct. it need not.
> I'm of the belief RPKI should NOT be on the critical path, but instead
> focus on Internet number resource certifi
ing security rely on dns and dns security. not a really great
> plan.
Right, I've heard the circular dependency arguments. So, are
you suggesting the RPKI isn't going to rely on DNS at all?
I'm of the belief RPKI should NOT be on the critical path, but instead
focus on Internet
On Mon, Jan 24, 2011 at 9:16 PM, Danny McPherson wrote:
>
> On Jan 24, 2011, at 9:02 PM, Joe Abley wrote:
>>
>> In this case the DNS delegations go directly from RIR to C; there's no
>> opportunity for A or B to sign intermediate zones, and hence no opportunity
>> for them to indicate the legiti
It's in-band only in the sense of delivery. The worst that a
corruption of the underlying network can do to you is deny you
updates; it can't convince you that a route validates when it
shouldn't. And even denying updates to your RPKI cache isn't that
bad, since the update process doesn't really
On Jan 24, 2011, at 9:02 PM, Joe Abley wrote:
>
> In this case the DNS delegations go directly from RIR to C; there's no
> opportunity for A or B to sign intermediate zones, and hence no opportunity
> for them to indicate the legitimacy of the allocation.
>
> As a thought experiment, how would
> I just don't like the notion of deploying a brand new system
you want certificates etc? or did you plan to reuse dns keys?
if the former, than all you are discussing is changing the transport to
make routing security rely on dns and dns security. not a really great
plan.
if the latter, then
On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote:
> I just don't like the notion of deploying a brand new system with data that
> at the end of the day is going to look an awful lot like the existing
> in-addr.arpa delegation system that's deployed, and introduce new
> hierarchical shared de
On 2011-01-24, at 20:59, Danny McPherson wrote:
> On Jan 24, 2011, at 8:48 PM, Randy Bush wrote:
>
>>> And now that DNSSEC is deployed
>>
>> and you are not sharing what you are smoking
>
> root and .arpa are signed, well on the way, particularly relative
> to RPKI.
>
> Incremental cost of s
On 2011-01-24, at 20:24, Danny McPherson wrote:
>
> Beginning to wonder why, with work like DANE and certificates in DNS
> in the IETF, we need an RPKI and new hierarchical shared dependency
> system at all and can't just place ROAs in in-addr.arpa zone files that are
> DNSSEC-enabled.
In
s opposed to continuing development, deployment and
operationalizing and dealing with all the political issues with
deploying a new RPKI system -- hrmm.
And again, I'm not opposed to RPKI and know we REQUIRE
number resource certification before we can secure the routing
system. I just don&
> And now that DNSSEC is deployed
and you are not sharing what you are smoking
> and DANE is happening
see above
randy
On Jan 24, 2011, at 8:32 PM, Randy Bush wrote:
> let's wind the wayback machine to 1998
>
>http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00
Yep, read that way back when it was posted initially, and again
a short while back, makes good sense, methinks.
And now that DNSSEC is
> Beginning to wonder why, with work like DANE and certificates in DNS
> in the IETF, we need an RPKI and new hierarchical shared dependency
> system at all and can't just place ROAs in in-addr.arpa zone files
> that are DNSSEC-enabled.
let's wind the wayback machine to 1998
http://tools.ietf
ning to wonder why, with work like DANE and certificates in DNS
in the IETF, we need an RPKI and new hierarchical shared dependency
system at all and can't just place ROAs in in-addr.arpa zone files that are
DNSSEC-enabled.
--but very happy we have some progress for Internet number resource
certification.
-danny
thanks john. your consideration to the ops community is appreciated.
> ARIN continues its preparations for offering production-grade resource
> certification services for Internet number resources in the region.
> ARIN recognizes the importance of Internet number resource
> certific
ilto:arin-annou...@arin.net>>
Subject: [arin-announce] ARIN Resource Certification Update
ARIN continues its preparations for offering production-grade resource
certification
services for Internet number resources in the region. ARIN recognizes the
importance
of Internet number resource cer
rrect certification policies.
As origin validation will be rolled out over years coverage will be
spotty for a long time. Hence a normal operator's policy should not
be overly strict, perhaps preferring valid announcements and giving
very low preference, but still using, invalid ann
rran
> Date: January 6, 2011 11:08:39 AM EST
> To: "George, Wes E [NTK]"
> Cc: "arin-disc...@arin.net"
> Subject: Re: [arin-discuss] Important Update Regarding Resource Certification
>
> On Jan 6, 2011, at 9:32 AM, George, Wes E [NTK] wrote:
>
>>
alex, i am not gonna argue with you.
96% of your users will be happy for you to do everything for them,
despite the fact that the wrong holder has the keys (and, as john says,
the liability).
but 96% of your address space, i.e. the large holders, will want to hold
their own keys and talk up/dow
On 4 Oct 2010, at 23:18, Randy Bush wrote:
1) We have not implemented support for this yet. We plan to go live
with the fully hosted version first and extend it with support for
non-hosted systems around Q2/Q3 2011.
this is a significant slip from the 1q11 we were told in prague. care
to expl
> 1) We have not implemented support for this yet. We plan to go live
> with the fully hosted version first and extend it with support for
> non-hosted systems around Q2/Q3 2011.
this is a significant slip from the 1q11 we were told in prague. care
to explain.
> Randy Bush who is cc-ed may be ab
; in the system. However, other security layers are implemented to ensure
> that for a given LIR only those users that have the 'certification'
> group enabled are *authorised* to use the hosted system -- and thereby
> the applicable keys.
>
But by the very nature, the adminis
Authority, then I think that would practically
> ruin the chances of Certification actually ever taking off on a large
> scale.
>
> -Alex
No... I'm saying that if ISPs aren't the only entities that hold their
private keys, then they aren't the only entities that can sign
around RPKI Resource Certification that have
been held up to now have largely revolved around infrastructure and
policy topics. I would like to move away from that here and discuss
what kind of value and which features can be offered with
Certification for network administrators around the world.
' and the security
>> structure of the [ripe part of the] rpki is a broken.
>>
>> randy
In the hosted implementation the RIPE NCC currently has, only a registered
contact for an LIR with whom we have a business relationship has access to
the secured LIR Portal in which the Certificati
qu...@ripe.net wrote:
Message: 1
From: Alex Band
Date: Sun, 3 Oct 2010 19:08:33 +0200
To: ncc-services...@ripe.net,
routing...@ripe.net
Subject: [routing-wg] RPKI Resource Certification: building features
Most of the discussions around RPKI Resource Certification that have =
been held up to now h
rpki is a broken.
randy
In the hosted implementation the RIPE NCC currently has, only a
registered
contact for an LIR with whom we have a business relationship has
access to
the secured LIR Portal in which the Certification system is embedded.
The reason to offer a hosted system initially,
On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:
>> Do you think there is value in creating a system like this?
>
> yes. though, given issues of errors and deliberate falsifications, i am
> not entirely comfortable with the whois/bgp combo being considered
> formally authoritative. but we have to
> Do you think there is value in creating a system like this?
yes. though, given issues of errors and deliberate falsifications, i am
not entirely comfortable with the whois/bgp combo being considered
formally authoritative. but we have to do something.
> Are there any glaring holes that I miss
Most of the discussions around RPKI Resource Certification that have been held
up to now have largely revolved around infrastructure and policy topics. I
would like to move away from that here and discuss what kind of value and which
features can be offered with Certification for network
85 matches
Mail list logo
