Re: G root servers unreachable via ICMP(v6)

[Robert Kisteleki]

However, from several sites, either on IPv4 or IPv6, I cannot ping(6) 
them. Is it by design, or it's an issue?


I believe g-root never answered ping requests. Others have been for a 
looong time (ever?) with some exceptions - those enabled it a few years ago.


Robert

Re: FYI - 2FA to be come mandatory for ARIN Online? (was: Fwd: [arin-announce] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts

[Robert Kisteleki]

On 2022-05-30 11:45, t...@pelican.org wrote:

On Sunday, 29 May, 2022 06:04, "Owen DeLong via NANOG"  said:


I use google auth for several forced 2FA sites and a few sites where what I am
protecting is worth the hassle. One difficulty that quickly emerges is managing
and finding the correct Totp in the long unsorted list.


In case it's of help, Authy seems a much-improved UI over Google Auth, 
including searching, and sync between devices, so e.g. your tablet can be your 
back-up key if your phone dies, is replaced, etc.


For a while google authenticator did not let you "export" (copy to 
another device) for "security reasons". Nowadays it does, not sure since 
exactly when. It also lets you search, so in these regards they are 
probably on par now.


Robert

Re: Gmail (thus Nanog) rejecting ipv6 email

[Robert Kisteleki]

Accepting mail for delivery, and then either silently dropping it, delaying it 
for days, or putting mail that in no way resembles spam into a spam folder 
seems a little worse than “doing what the standards say”. If you’re going to 
decide, on little or no evidence, that a message is spam or otherwise does not 
deserve to get delivered, the least you could do is to bounce it so that the 
sender is aware. No need to generate a bounce mail that could turn into 
backscatter; just reject the mail during the SMTP exchange.

Jim Shankland



I think they have turned some knobs recently (or rather, they 
continuously do). Yesterday's soft reject (i.e. mail ending up in the 
spam folder) became a hard reject. I guess it's possible to argue both 
ways - at least the soft reject could be trained not to categorise real 
mail as spam. With a hard reject that problem is shifted entirely to the 
sender.


Robert

Re: Gmail (thus Nanog) rejecting ipv6 email

[Robert Kisteleki]

On 2022-04-03 07:18, Owen DeLong via NANOG wrote:
I’ve not experienced this problem sending emails via IPv6 to gmail 
destinations from my personal domain.


(delong.com )

Likely this email will, in fact, get sent to GMAIL via IPv6.

I do have good SPF and DKIM records and signing and a reasonable DMARC 
policy set up.


If ISC doesn’t have that yet, it might be a better alternative than 
turning off IPv6.


If that doesn’t solve it, I can reach out to someone at Google who can 
likely get the right parties involved.


Owen


I think it has been argued before that having a different email 
acceptance policy over IPv4 vs IPv6 is essentially a layering violation. 
I'm sympathetic to that argument.


More to the point: *you* could do this and there are a number of other 
clueful people who can make this work today. And when Google changes 
their rules (that you'll have to learn about once you hit the next 
wall), then you adjust. And you keep on doing this whack-a-mole game.


Of course there's an argument that say "mom and pop should not run their 
own mailserver, there are professionals for that!" but at the end of the 
day what this really serves is deliberate and pre-mediated 
centralisation, slowly but steadily stamping out small players.


Robert

Re: Authoritative Resources for Public DNS Pinging

[Robert Kisteleki]

On 2022-02-09 10:32, Brian Turnbow via NANOG wrote:


It wouldn't be too hard for ripe to setup a dns record for  ping.ripe.net and  
point it towards a local anchor for each request.


Yes this is possible and it's an interesting engineering problem (as we 
also have 11000 vantage points with known geolocation and topolocation 
to help here).


The idea will need vetting with the [atlas [anchor]] community though.


I think it could generate some interesting data for the atlas project as well.


It certainly would!


Once it becomes popular the anchor hosters may not be so happy  about the 
traffic they receive , but that is another story.


I imagine we could provide a means for anchors to opt out of this.

Robert

Re: OT: Re: Younger generations preferring social media(esque) interactions.

[Robert Kisteleki]

[...]
Keeping it simple so you can reach your result faster and most 
efficiently is often understood more by the kids than us geezers. 
While we are fighting about whether Discourse or Mailman are 
appropriate, the kids have probably dumped both and found something 
that gets them to the promised land 5 seconds after they install the app.


...only to end up with yet another account at yet another data mining 
(future) monopolist butchering standards... I'm all for moving with the 
flow and embrace new things as long as it's based on open standards, 
open protocols, does not lock people in to a specific platform, etc., is 
decentralised and federated and gives users the choice (e.g. choice of 
MUA / MTA, or XMPP client, etc.). The trend to force everything to 
web-based or only THAT particular app is a fundamental step backwards 
towards significant less of choice on the internet.


To just give in (or up) and say, well, that's what the youngsters now 
prefer is to move even more towards a world dominated by a few global 
monopolistic players who don't give a darn about open standards, open 
protocols, not locking people in, decentralisation and fedaration...
And youngsters - as with anything in life - need to be educated and made 
aware of that (spoken as a former teacher).


Sec


(Excuses for not being a "real NANO", but have strong ties.)

I would not use the same strong words, but I agree with this in spirit.

As of today, email is the ultimate standard that helps me manage my 
relations in a similar manner to almost all of the professional 
communities I'm interested in (*). I do observe that multiple of them 
have proposals to move on to something else, in many cases to walled 
gardens. This bears a number of risks towards participation and keeping 
(long term) history.


As for participation: I'm concerned that for me to keep up being 
involved in these communities, I'd have to engage an ever increasing 
number of (proprietary) platforms *all of which are incompatible with 
each other*. Different communities adopt different solutions, so the 
list started to include FB, github, discord, mattermost, etc. and will 
soon include signal, telegram, and everything else in between. A common 
denominator, being almost always email, is badly needed. And exists. 
OTOH once this becomes unbearable, I *will* stop participating in some. 
As for NANOG, such a move will surely make otherwise valuable members 
tune out?


As for keeping history: there's surely a break when the whole community 
is moved to a new platform. If that ever happens again, there's another 
discontinuity. This is only worse with proprietary platforms where 
exporting / backing up history for long term preservation is likely 
hard, if not entirely impossible.


All in all, I'm happier if email continues to be the backbone of 
communication here.


Robert

(*) sadly, this is already not entirely true

Re: cloud automation BGP

[Robert Kisteleki]

Hi,

It uses RIS Live (https://ris-live.ripe.net) under the hood.

Robert


On 2020-09-29 15:36, Graham Johnston wrote:

Does anyone have a quick answer as to what public data sources are used? I 
tried looking at the main github page for the project but I either missed it or 
it isn't there.

Graham


-Original Message-
From: Randy Bush

have folk looked at https://github.com/nttgin/BGPalerter

randy

Re: This DNS over HTTP thing

[Robert Kisteleki]

> The bare about:config pref you want is "network.trr.mode".  Short and
> sweet of it, set to 5 (off by choice), and it should disable the
> function entirely.  3 would be the opposite: always use it.

Thank you, IMO this is by far the most useful piece of information on
the subject!

Robert

Re: new BGP hijack & visibility tool “BGPalerter”

[Robert Kisteleki]

On 2019-08-16 14:13, Valdis Klētnieks wrote:
> On Fri, 16 Aug 2019 11:02:41 +0200, Robert Kisteleki said:
>> Hi,
>>
>> On 2019-08-15 17:38, Christopher Morrow wrote:
>>> This looks like fun!
>>> (a few questions for the RIPE folk, I think though below)
>>>
>>> What is the expected load of streaming clients on the RIPE service? (I
>>> wonder because I was/am messing about with something similar, though
>>> less node and js... not that that's relevant here).
>>
>> One of the (IMO) most useful features is that you can filter what you
>> want to receive. In fact this makes the service useful :-) So unless you
>> want to tune in to a significant portion of BGP chatter, the load should
>> not be substantial.
> 
> I think Chris's question is more "Is RIPE going to be OK if a lot of people 
> ask
> for the extra-chatty feed?"

Yes, good point. Of course it could be a problem if too many clients ask
for too much data like a full feed... we're not prepared to provide that
on a large scale. For the moment we're looking at the effects of what
people need and if we can handle it with what we have built.

Robert



signature.asc
Description: OpenPGP digital signature

Re: new BGP hijack & visibility tool “BGPalerter”

[Robert Kisteleki]

Hi,

On 2019-08-15 17:38, Christopher Morrow wrote:
> This looks like fun!
> (a few questions for the RIPE folk, I think though below)
> 
> What is the expected load of streaming clients on the RIPE service? (I
> wonder because I was/am messing about with something similar, though
> less node and js... not that that's relevant here).

One of the (IMO) most useful features is that you can filter what you
want to receive. In fact this makes the service useful :-) So unless you
want to tune in to a significant portion of BGP chatter, the load should
not be substantial.

> I hadn't seen the ripe folk pipe up anywhere with what their SLO/etc
> is for the ris-live service? (except their quip about: "used to run in
> a tmux session I had to occassioanlly ssh into  and restart when
>  rebooted" I believe the end of that quip in Iceland was: "and
> now its' running as a real service")

It's in between those. We now have a conscious setup which should also
be able to scale up, but bits and pieces (like full monitoring of the
service) are still being developed.

> Also, one of the strengths to the 'monitoring as a service' folks is
> their number of collection points and breadth of ASN to which they
> interconnect those points/ RISLive, I think, reports out from ~37 or
> so RIPE probes, how do we (the internet) get more deployed (or better
> interconnection to the current sets)? and maybe even more
> imoprtantly... what's the right spread/location/interconnectivity map
> for these probes?

RIS Live provides data from RIS, which has a bunch of collectors around
the world (see
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-peering-policy)
with many hundreds of peering sessions. But it is by no means complete
in terms of coverage.

If and how the community (NANOG or RIPE or else) should work on optimal
data collection is indeed a useful discussion to have.

Cheers,
Robert

> thanks! for showing what's possible with tooling being developed by
> like minded individuals :)
> 
> -chris

spam and GDPR (was something else)

[Robert Kisteleki]

On 2019-06-02 00:51, Mark Rousell wrote:
> On 31/05/2019 16:02, Niels Bakker wrote:
>> Which is why we now have GDPR.  Care, or get fined.
> 
> Not quite so simple, though, is it. If you want to make a complaint then
> you have to get your EU national data protection regulator interested.

What seems to help in individual cases is to reply to real but otherwise
unwanted mails and remind the sender of GDPR violation. I got several
sources to stop sending me such mails. When using a templated answer, it
takes 5 seconds to do so.

Also, the correspondence may come handy later, should evidence need to
be presented.

Robert

CVV (was: Re: bloomberg on supermicro: sky is falling)

[Robert Kisteleki]

(this is probably OT now...)

> I'm pretty sure the "entire point" of inventing CVV was to prove you
> physically have the card.

Except that it doesn't serve that purpose. Anyone who ever had your card
in their hands (e.g. waiters) can just write that down and use it later
hence defeating the purpose of "physically having the card". (Call me
paranoid but I usually use a black pen to make the numbers undreadable
because of this, after my card (both sides) has been photocopied a
number of times...)

This has always been an amusing topic. At the end of the day it's a
financial risk management call from the banks -- as long as they lose
less money on the current system than the cost of fraud, things wiull
not change. Of course, they try to push those costs onto others as much
as possible, but that doesn't change the bottom line.

Robert

Re: G root not responding on UDP?

[Robert Kisteleki]

On 2016-04-14 14:29, Robert Kisteleki wrote:
> On 2016-04-14 13:30, Anurag Bhatia wrote:
>> Hello everyone
>>
>>
>> I wonder if it's just me or anyone else also finding issues in g root
>> reachability?
>>
>>
>> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work.
> 
> 
> It's not only you:
> 
> https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460574600&dnsmon.endTime=1460616600&dnsmon.ipVersion=both

... and it recovered already:

https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460595996&dnsmon.endTime=1460637996&dnsmon.ipVersion=both&dnsmon.timeWindow=42000

Robert

Re: G root not responding on UDP?

[Robert Kisteleki]

On 2016-04-14 13:30, Anurag Bhatia wrote:
> Hello everyone
> 
> 
> I wonder if it's just me or anyone else also finding issues in g root
> reachability?
> 
> 
> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work.


It's not only you:

https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460574600&dnsmon.endTime=1460616600&dnsmon.ipVersion=both

(shorter link: https://t.co/7lgnCFCEDZ)

Cheers,
Robert

Re: how to deal with port scan and brute force attack from AS 8075 ?

[Robert Kisteleki]

> How do you deal with such massive amount of 'illegal' traffic ?

Move SSH to a different port. Better yet, use IPv6 only :-)

Robert

Password storage (was Re: gmail security is a joke)

[Robert Kisteleki]

> Bcrypt or PBKDF2 with random salts per password is really what anyone
> storing passwords should be using today.

Indeed. A while ago I had a brainfart and presented it in a draft:
https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00

It seemed like a good idea at the time :-) It didn't gain much traction though.

Robert

Re: dns on fios/frontier

[Robert Kisteleki]

>>> anyone on fios/frontier can please run a quickie and see if you can get
>>> to http://psg.com/?  have a net friend who can not from multiple hosts
>>> on their home lan and he has rebooted router.  called support and they
>>> showed their sunday best "the web site is down."  sigh.
>> https://atlas.ripe.net/probes/13318/
> 
> two things.  
> 
> so how did you find it?  i was wondering if i could find a useful atlas
> probe or nlring node, and how to find them.

https://atlas.ripe.net/docs/rest/#probe
or more specifically:
https://atlas.ripe.net/api/v1/probe/?tags=fios (it gives exactly one result
at the moment -- the above mentioned one. It's useful if people actually tag
their probes...)

About Ring: we're not authoritative -- I believe http://map.ring.nlnog.net/ is.

> secondly, i gotta snark that the ui maximizes the eurocracy to do a
> seemingly simple
> dig @probe psg.com. a
> and
> ping psg.com
> and it does not even serve coffee during the hour the dig and ping are
> "running."  (quaint use of the gerund).

I'd like to draw attention to the "one-off measurement" feature, which
responds within 10-30 seconds or so.

Indeed, it serves no coffee :-(

> i am not great at json, but looks to me as if it is a dns failure
> 
> [{"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":163,"msm_id":1964820,"msm_name":"Tdig","prb_id":13318,"resultset":[{"af":4,"dst_addr":"10.0.0.13","lts":163,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":61959,"NSCOUNT":3,"QDCOUNT":1,"abuf":"8geBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMAAIAAQAADhAABgNyaXDADMAMABwAAQAADhAAECABBBgAAQAAAGLAYQABAAEAApzNAASTHAAnwGEAHAABAAGYeQAQIAEEGAABOQ==","rt":175.454,"size":175},"src_addr":"10.0.1.100","subid":1,"submax":3,"time":1429553733},{"af":4,"dst_addr":"38.103.8.115","lts":164,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":10350,"NSCOUNT":3,"QDCOUNT":1,"abuf":"KG6BgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAAYDcmlwwAzADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMABwAAQAADhAAECABBBgAAQAAAGLANQABAAEAAMIIAASTHAAnwDUAHAABAADCCAAQIAEEGAABOQ==","rt":370.067,"size":175},"src_addr":
 "
1
>  
> 0.0.1.100","subid":2,"submax":3,"time":1429553734},{"af":6,"dst_addr":"2001:550:102:301::13","lts":165,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":47682,"NSCOUNT":3,"QDCOUNT":1,"abuf":"ukKBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADg4ABJMcAD7ADAACAAEAAA4OABIEbmxucwdnbG9ibml4A25ldADADAACAAEAAA4OAAYDcmlwwAzADAACAAEAAA4OAALADMAMABwAAQAADg4AECABBBgAAQAAAGLAUwABAAEAApzLAASTHAAnwFMAHAABAAGYdwAQIAEEGAABOQ==","rt":1.345,"size":175},"src_addr":"2001:550:102:301::1001","subid":3,"submax":3,"time":1429553735}],"timestamp":1429553733,"type":"dns"}]

No, it's ok, see https://atlas.ripe.net/measurements/1964820/#!map

> looks pingable
> 
> [{"af":4,"avg":77.535333,"dst_addr":"147.28.0.62","dst_name":"147.28.0.62","dup":0,"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":166,"max":78.025,"min":77.132,"msm_id":1964819,"msm_name":"Ping","prb_id":13318,"proto":"ICMP","rcvd":3,"result":[{"rtt":78.025},{"rtt":77.449},{"rtt":77.132}],"sent":3,"size":48,"src_addr":"10.0.1.100","step":240,"timestamp":1429553736,"ttl":239,"type":"ping"}]

Yep.

Cheers,
Robert

> http://dnsviz.net/d/psg.com/dnssec/ thinks the dnssec glorp is fine.
> 
> randy
> 

Re: Getting hit hard by CHINANET

[Robert Kisteleki]

On 2015-03-17 3:06, Terrance Devor wrote:
> Hello Everyone,
> 
> I really hope this is not against group policy etc.. however our network is
> being hit
> hard by a China IP for the past 6 months. Our systems our up to date,
> passwordless
> ssh etc.. but they're DOS attempts are getting more and more aggressive.
> Tried to
> contact their phone number to no success (not valid). Emails don't get any
> response.
> The IP is 218.77.79.43. Do we have any options?
> 
> Terrance
> 

If you don't want to spend more than 2 minutes on this, then move sshd to a
different (randomish) port. Sounds naive, but it's dirt cheap and really helps.

Robert

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Robert Kisteleki]

On 2014-10-23 9:15, Matt Palmer wrote:
> On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jeffrey Ollie wrote:
>> To achieve the level of integration that timedated has with the rest
>> of systemd would require more than just putting code into timedatectl
>> to write out /etc/ntpd.conf and starting a service.  timedated talks
>> to networkd (that
>> DHCP server that everyone is hating on as well) in real-time to
>> determine the state of the network and to get any NTP servers that
>> were sent in DHCP packets.  To do that for chronyd or ntpd in the same
>> way would require code changes and the systemd developers didn't want
>> to do the work,
> 
> This is the core problem with systemd, in my mind -- and what has gotten
> Linus, amongst other people, so thoroughly cheesed off with the systemd
> devs.  They don't play well with other children.  They don't appear
> particularly interested in reusing any existing code, because it's a lot
> more fun to write new code.  I'm a strong proponent of Joel Spolsky's views
> on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the

http://www.joelonsoftware.com/articles/fog69.html

> same problems will come to haunt systemd on its way from being the new kid
> on the block to being legacy code[1].
> 
> - Matt
> 
> [1] A computer industry term which means, "it works".
> 
> 

Re: RIPE Atlas data parsing

[Robert Kisteleki]

On 2014.05.27. 21:28, Ca By wrote:
> Folks,
> 
> Yes, RIPE Atlas is great.  It  generates output as JSON.
> 
> Is there  dummy tool for summarizing this JSON data and possibly
> visualizing it?  I could write my own, but i imagine someone has
> already done this somewhere.  No?
> 
> CB
> 

These may help:

https://github.com/RIPE-NCC/ripe.atlas.sagan

Re: crave your indulgence

[Robert Kisteleki]

On 2014.05.27. 20:28, manning bill wrote:
> If you wouldn’t mind a quick tracerooute -  Can you confirm reachability to 
> the following:
> 
> 2001:500:84::b
> 
> Thanks in advance.
> 
> /bill
> Neca eos omnes.  Deus suos agnoscet.


There should be a tool for this kind of thing! :-)

https://atlas.ripe.net/atlas/udm.html?msm_id=1666831

or just the data (~1MB):

https://atlas.ripe.net/api/v1/measurement/1666831/result/

Cheers,
Robert

Re: ANNOUNCE: bgptables.merit.edu - understanding visibility of your prefix/AS

[Robert Kisteleki]

On 2012.01.19. 7:57, Suresh Ramasubramanian wrote:
> On Wed, Jan 18, 2012 at 8:07 PM, Robert Kisteleki  wrote:
>> One can also try RIPEstat for this: http://stat.ripe.net/
>>
>> Amongst other modules it gives full (~10 year) BGP history for prefixes.
> 
> Does it also give a similar history for ASN announcements?I see a
> lot many shady ASNs that simply move from one prefix to another, in
> batches
> 

Yes. See for example (only the routing module):

http://stat.ripe.net/query/routing-history/AS?params={%27value%27:+%27AS%27}

You can turn on the "first transit AS" with the checkbox on the top right.

Robert

Re: ANNOUNCE: bgptables.merit.edu - understanding visibility of your prefix/AS

[Robert Kisteleki]

On 2012.01.18. 15:22, Arturo Servin wrote:
> 
>   For example for any given prefix to get which ASNs have originated that 
> prefix over time and when.
> 
>   I think that could be interesting for discovering if a prefix has been 
> hijacked in the past.
> 
>   RIS from RIPE NCC provides something like this:
> 
> http://www.ripe.net/data-tools/stats/ris/routing-information-service
> 
>   We have used it to verify some "suspicious" announcements of prefixes. 
> 
> Regards,
> as

One can also try RIPEstat for this: http://stat.ripe.net/

Amongst other modules it gives full (~10 year) BGP history for prefixes.

(Disclaimer: our team is working on this tool.)

Robert

Re: Weekly Routing Table Report

[Robert Kisteleki]

On 2011.03.19. 23:40, Geoff Huston wrote:
> 
> On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote:
> 
>> On Sat, 19 Mar 2011, Routing Analysis Role Account wrote:
>>
>>> Number of 32-bit ASNs allocated by the RIRs:   1207
>>> Prefixes from 32-bit ASNs in the Routing Table:   1
>>
>> Is the report not getting the routes from the real 32bit ASNs or is the 
>> above figures really accurate?
> 
> Its probably not getting the routes - I see 915 AS's in the routing table 
> using 32 bit AS numbers (http://www.potaroo.net/tools/asn32/)
> 
>   Geoff

In RIS we saw 918 32 bit ASNs advertising about 2200 prefixes on 2011-03-19.

Robert

Re: IDS IPS

[Robert Kisteleki]

http://en.wikipedia.org/wiki/ISS

On 2010.09.22. 18:29, Joshua William Klubi wrote:

What is ISS

Joshua

On Wed, Sep 22, 2010 at 4:24 PM, Adefisayo Adegokewrote:


ISS  ideal for the Defense and Banking industry ...

'Ayo

On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi<
joshua.kl...@gmail.com>  wrote:


Hi,

I have been tasked to get the best IDS and IPS for our internal LAN and
WAN
in a Banking infrastructure.
I would like ask if any one has deployed in any network with such
technology, and also if any one can recommend
a very good IDS and IPS for me to recommend to management

Thank you.

Joshua





--
... the sky is too low to be my limit.

 Success is getting what you want, happiness is wanting what you get -
Ingrid Bergman

Re: ip block history.

[Robert Kisteleki]

On 2010.09.15. 4:50, Richard Barnes wrote:

RIPE has been developing a couple of projects to support this sort of
history searching:

Internet Resource Database (INRDB):


Resource EXplainer (REX):



Indeed, REX is our prototype tool for these kind of questions. It has its 
own limitations, but so far it's the best tool I'm aware of.


Robert

Re: Note change in IANA registry URLs

[Robert Kisteleki]

On 2010.04.02. 18:16, David Conrad wrote:

On Apr 1, 2010, at 11:42 PM, Robert Kisteleki wrote:

I don't know what good reasons you might have to pull down the current
URLs.


Because the content has changed from arbitrary ASCII text files into more
easily parseable XML and backporting to those arbitrary ASCII text files
has proven too error prone and labor intensive.

Regards, -drc


You're confusing two things: URL and content. According to the announcement, 
TXT files will be generated still. Why, again, must the URL change?


Robert

Re: Note change in IANA registry URLs

[Robert Kisteleki]

On 2010.04.02. 6:16, Leo Vegoda wrote:

On Mar 31, 2010, at 8:22 PM, Dan White wrote:

[…]


http://www.iana.org/assignments/ipv4-address-space/


I think it's worth pointing out again that the URLs for IANA registries
have changed and the old URLs, like the one above, will be going away
from next week. Anyone automatically parsing the registries should make
sure they adjust their scripts before then.


I don't know what good reasons you might have to pull down the current URLs. 
Please keep them working.


Recommended reading:
http://www.w3.org/Provider/Style/URI

Robert

Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup)

[Robert Kisteleki]

I must observe that these are not really the links you'd want to give your 
end users to check out. Their audience is very different. While the article 
on RIPE Labs comes close, they don't really answer the "does it work or does 
it not?" question with a green/red light, and they don't provide a good 
explanation to the audience Randy is referring to.


Robert


On 2010.03.30. 11:29, Phil Regnauld wrote:

Randy Bush (randy) writes:


i.e. what can we do to maximize the odds that the victim will quickly
find the perp, as opposed to calling our our tech support lines?


Ah yes, there was the second good reason for actually helping netops
and security officers :)

Tools:

https://www.dns-oarc.net/oarc/services/replysizetest

https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources,
under troubleshooting:

http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues
http://secspider.cs.ucla.edu/

Info sheets:


http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010
(click English, top right)

... plenty of links there too.

Cheers,
Phil

Re: interger to I P address

[Robert Kisteleki]

Colin Alston wrote:

On 2008/08/27 05:22 PM Dave Israel wrote:


Normally, I don't participate in this sort of thing, but I'm a sucker 
for a "there's more than one way to do it" challenge.


Aww come on, C gets way more "fun" than that ;)

#define _u8 unsigned char
#define _u32 unsigned long

int main(void) {
_u32 ipn = 1089055123;
_u8 ipa[3];
_u8 oct = 0;


for (oct=0; oct <4; oct++){
ipa[oct] = (char)(
(ipn & (0xFF00 >> (8*oct))) >> (8*(3-oct))
);
}

printf("%d.%d.%d.%d\n", ipa[0], ipa[1], ipa[2], ipa[3]);

return 0;
}


Actually, who needs loops for that?

#include 

int main()
{
unsigned i = 1089055123;
printf("%d.%d.%d.%d\n",
(unsigned char)(((char*)&i)[3]),
(unsigned char)(((char*)&i)[2]),
(unsigned char)(((char*)&i)[1]),
(unsigned char)(((char*)&i)[0])
);
return 0;
}


Robert

Re: Validating rights to announce a prefix

[Robert Kisteleki]

[EMAIL PROTECTED] wrote:
Okay, I admit I haven't paid the closest attention to RPKI, 
but I have to ask: Is this a two-way shared-key issue, or 
(worse) a case where we need to rely on a central entity to 
be a key clearinghouse?


The reason why I mention this is obvious -- the entire PKI 
effort has been stalled (w.r.t. authority) because of this 
particular issue.


Who says there needs to be a PKI infrastructure in order to
do this? There are other ways of authenticating data. For instance
ARIN could hold the data that they have validated on their own
servers and people could use HTTPS queries to ensure that they
get the answers that they thought they would get.


I must point out that HTTPS is still in PKI land - it's just "another one", 
inviting otherwise unrelated parties (like Verisign et al.) into the system.


As for how the address owner delegates the right to announce 
a prefix, they could either operate their own database and

ARIN would have a pointer to it, or they could register the
data in ARIN's database by some secure means. There is no
reason why "secure means" could not include various out of
band authentication systems.


The principles for this are included in the SIDR efforts.


People are too hung up on cryotographically secure PKI systems
which are way overkill for this problem. In fact, it should be
possible to design an architecture that allows for an easy upgrade
to PKI if it should be determined at some future date, that PKI
is necessary.


It's hard to switch to a more secure method later on if you start with a 
less secure one. So, "upgrading" to PKI from something else only makes sense 
if that previous system was secure enough - but then why would you want to 
change?


Robert


--Michael Dillon

Re: Validating rights to announce a prefix

[Robert Kisteleki]

[EMAIL PROTECTED] wrote:

Rather than rushing off and hacking up some code, is it possible
for a group of network operators to meet formally, in some venue
or other, and set out the requirements for such a system and the
architecture of such a system? 


--Michael Dillon



You might want to take a look at the IETF SIDR working group's efforts.

Robert

https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Robert Kisteleki]

Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put "https://"; in 
front of "www"?


I understand this is a huge can of worms, but maybe it's time to change the 
default behavior of browsers from http to https...?


I'm sure it's doable in FF with a simple plugin, one doesn't have to wait 
for FF4. (That would work for bookmarks too.)


Robert