Re: RFC 1918 network range choices
Interesting you call sections 2,4,5 a security model when section 6 explicitly states "Security issues are not addressed in this memo.” Sections 2, 4, and 5 are motivational and design considerations. Using RFC1918 space is not and should not be considered a security practice. /Ryan Ryan Harden Research and Advanced Networking Architect University of Chicago - ASN160 P: 773.834.5441 > On Oct 6, 2017, at 8:51 AM, Joe Klein <jskl...@gmail.com> wrote: > > Which part? The allocation of the addresses or the security model (section > 2, 4 & 5)? > > Note: Very few system, network, or security professionals have even read > anything besides section 3, the private address allocation. Could be why > we have some many compromises --- just saying. > > Joe Klein > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Thu, Oct 5, 2017 at 4:28 PM, Randy Bush <ra...@psg.com> wrote: > >>>> The answer seems to be "no, Jon's not answering his email anymore". >> >> jon was not a big supporter of rfc1918 >> signature.asc Description: Message signed with OpenPGP
Re: NIST NTP servers
_Everything_ has vulnerabilities and using _any_ external source opens your network and infrastructure to disruptions. NTP has been used for DDoS amplification attacks recently, but so has DNS and other well known/heavily used protocols. With the right protections, syncing with an external NTP source is perfectly acceptable and safe. Further, it’s generally a good idea to ‘peer’ (not just sync) your NTP servers with a few external sources. This removes the dependence on a single source and helps ensure that your time source agrees with the rest of the world. Peering requires interaction with the owners of the remote site, which establishes a basic level of trust that they’ll provide an accurate and stable service. I’ve attached a diagram (sanitized) of what our NTP service will look like after an upcoming refresh. All external sources are trusted and will be peered. All time devices peer with four other sources to ensure there is always a live source to sync/peer with. A DNS record with round-robin is used for local clients to connect to the local Stratum 2 devices. The Stratum 1 GPS will not be directly accessible by users. /Ryan [cid:5676FF89-CBC8-42F7-84CE-69F431C23E48@int.ancker.net] Ryan Harden Research and Advanced Networking Architect University of Chicago - ASN160 P: 773.834.5441 On May 10, 2016, at 5:48 AM, Steven Miano <mian...@gmail.com<mailto:mian...@gmail.com>> wrote: NTP has vulnerabilities, so using an external source opens your networks and infrastructure to disruptions. Going with an internal GPS/GLONASS/RADIO based S1 allows you to restrict incoming traffic and not rely on volunteers or external entities (which may undergo maintenance or budget issues). My preference is more so something akin to the GLN180PEX (I am not affiliated or paid to endorse this product). It allows you to use commodity hardware (like a decommissioned 1U or several preferably) and creation of ones own reliable internal time source(s). Introducing black boxes into a production (revenue generation or expected services by paying customers) environment is undesirable. From there setting up NTPd, Chronyd, and PTPd is up to you. Relying on satellites may seem like just another external reliance, but the next life is proposing a design life of 12 years. On Mon, May 9, 2016 at 11:12 PM, Majdi S. Abbas <m...@latt.net<mailto:m...@latt.net>> wrote: On Tue, May 10, 2016 at 03:08:16AM +, Mel Beckman wrote: NTP has vulnerabilities that make it generally unsuitable for provider networks. I strongly recommend getting a GPS-based time server. These are as cheap as $300. Here is one I use quite a bit: So how does this stop from distributing time to their customers via NTP? GPS doesn't save the protocol, in particular where the S1 clocks involved are embedded devices with rather coarse clocks and timestamping. --msa -- Miano, Steven M. http://stevenmiano.com
Amazon AWS Engineer
Could an Amazon AWS Engineer contact me off list. We're seeing what is perceived to be performance issues and I'd like to discuss what the expected performance should be. The Amazon AWS support channels don't appear to be meant for network type question. Thanks /Ryan Ryan Harden Senior Network Engineer University of Chicago - AS160 P: 773-834-5441 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 31, 2013, at 1:10 AM, Timothy Morizot tmori...@gmail.com wrote: I've been in the process of rolling out IPv6 (again this night) across a very large, highly conservative, and very bureaucratic enterprise. (Roughly 100K employees. More than 600 distinct site. Yada. Yada.) I've had no issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 model. In fact, the IPv6 model has generally been much more straightforward and easy to implement. So I'm a large enterprise operator, not an ISP. Convince me. Because I don't see any need. And if I don't, I'm hard-pressed to see why the IETF would. Scott I haven't seen anyone in this thread argue that DHCPv6+RA doesn't work. So we'd all expect that you'd do just fine deploying that way for your large enterprise. The point is that there are some (And based on the thread here and over at IPv6-OPS, not just a couple) operators who wish or are required to do things differently. I remember thinking how stupid it was we had to either statically configure or run DHCPv6 (which a lot of clients didn't support) for the sole purpose of handing out name servers, then we finally got around to RFC6106. There were lots of people who just couldn't understand why you'd ever want your router handing out name servers/dns search lists. Sure DHCPv6 was/is the 'right' and 'clean' way to do it, but it shouldn't be required to make IPv6 functional. Clearly the IETF agreed, eventually. IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way they do IPv4. /Ryan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 31, 2013, at 2:16 PM, Tony Hain alh-i...@tndh.net wrote: Ryan Harden wrote: ... IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way they do IPv4. As I said in the response to Leo, this issue has been raised before and couldn't get traction because the combination of a one-size-fits-all mantra from the leadership with concession such that the dhcp model would be self-contained, would have led to the end of the RA model. You are correct, neither way is better, and both need to operate independently or in combination, but getting there requires a clear use case, or many similar cases, to make progress. I believe you are correct in that many people do use the dhcp option to assign the router, but quantifying that is a very difficult task because that community rarely worries about driving standards to get their way. I find that most of this community finds innovative ways to reuse tools defined for a different purpose, but its close enough to accomplish the task at hand while avoiding the cost of getting a vendor to build something specific. That is all fine until the original backer of the tool goes a different direction, and ongoing evolution requires someone to justify its continued support. The scattered community has so many different corner-case uses it is hard to make a clear and quantified need for what the tool should become. The primary reason that this is even a discussion is that the decision was made long ago in the DHCP WG to avoid bringing forward unused baggage from the evolution of IPv4 and dhcp by not bringing any options forward until someone documented an ongoing use for it. That remains the only real requirement I am aware of for getting a dhcp option copied forward from IPv4 to IPv6; document a widespread use case. This one has had an artificial requirement of getting past the dhcp vs. RA model wars, but that would have been, and still is easy enough to beat down with sufficiently documented use. Documented use is where things fail, because we loop back to the point about the people using it don't participate in driving the process to demonstrate how widespread the use actually is, and what specific functionality is being used to make sure the new definition is sufficient. Lee asked the question about use cases, and you were the only one that offered one with substance. Compound that with the point that nobody else jumped in with a 'me too', and the case could be made that you are looking for a standard to be defined around your local deployment choices. Not to say your deployment is isolated, wrong, or shouldn't be considered best-practice, rather that it is hard to demonstrate consensus from a single voice. Besides documenting the use case, it will help to fight off objections by also documenting why this innovative use is deployed rather than another widely deployed choice (in the case you present, why not 802.1X?, not that it is better, just 'why not' ; and I personally consider pre-dated or inconsistent implementations at deployment as a perfect justification, but that is just my take). At the end of the day, if operators don't actively participate in the standards process, the outcome will not match their expectations. Tony Couple things… It should be noted that I don't intend to use DHCPv6 to hand out gateway information. I expect DHCPv6+RA to continue to fulfill my needs. So any notion that I'm trying push anything to meet any local deployment choices can be stopped right there. However, I can understand that some places might and do want to deploy things in the scenario I outlined previously. Some would love to deploy IPv6 but are hamstrung by old processes or tools with stupid assumptions or dependencies. Are the processes stupid? yes, Should they be replaced? absolutely. Is explaining that you need to rebuild your processes and tools to support this IPv6 thing that a very small percentage of your customers have even heard of, let alone asked for easy or likely to get approved? no. I think you are absolutely correct in that the people who are stuck deploying with these scenarios don't participate in the standards process or even know where to start with getting their voice heard. I jumped into this conversation not because I have anything to lose or gain from it, but because I noticed the quick and deliberate efforts to brush
Re: turning on comcast v6
On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6. 'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything. Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use. /Ryan
Re: turning on comcast v6
On Dec 30, 2013, at 12:58 PM, Lee Howard l...@asgard.org wrote: 'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, Make sure you call IP family agnostic libraries and increase field sizes, then let it run and Rebuild your network security. DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. /Ryan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iOS 7 update traffic
To be honest, I don't see this as a problem at all. Use it as an excuse to upgrade your pipes, talk Akamai or CDN of choice into putting a cache on your network, or implement your own caching solution. As operators of the Internet we should be looking for ways to enable things like this, not be up in arms at Apple for releasing an update to their phone OS or making it available in a way that's inconvenient to our oversubscription policies. As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. This isn't a new phenomenon. I realize some of you are too cool for Apple, but paying attention to traffic trends and keeping abreast of how new software releases might affect your utilization is part of properly running a network. /Ryan Ryan Harden Senior Network Engineer University of Chicago - AS160 P: 773-834-5441 On Sep 19, 2013, at 1:22 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's sequentially. That way, you do not.. 1. Murder your last mike packet network, which is your bandwidth bottleneck. 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. 3. Anger your paying customers who would like to use packet data successfully on an ios download day. These people (Apple) represent themselves as smart guys, but their actions reflect otherwise. I bet this would be a larger deal to Nanog people if your Internet stopped working as the result of 100% Linux adoption. That is very close to what this is.. Tens of millions of people trying to update their 13 ios devices at the same time. Who owns a single ios device? A household could do 5-10gb worth of updates in a single day.. I personally do not own an ios device, and I see close to 3 gigs worth of update traffic at my house. These things are everywhere, and this problem will not stop. Sent from my Mobile Device. Original message From: Mikael Abrahamsson swm...@swm.pp.se Date: 09/19/2013 11:16 AM (GMT-08:00) To: Warren Bailey wbai...@satelliteintelligencegroup.com Cc: Paul Ferguson fergdawgs...@mykolab.com,NANOG nanog@nanog.org Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013, Warren Bailey wrote: Why does apple feel it is okay to send every mobile device an update on a single day? They don't, these are users who actively goes into the software upgrade menu and pressing upgrade. I believe the nagging won't start for quite some time. -- Mikael Abrahamssonemail: swm...@swm.pp.se signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iOS 7 update traffic
On Sep 19, 2013, at 3:11 PM, Jeroen van Aart jer...@mompl.net wrote: On 09/19/2013 12:06 PM, Ryan Harden wrote: As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. The difference is there are now a couple more million devices out there than there were in 2007. And in 2007 there was just the one phone, now you have tablets and what have you. The effect has been relatively the same regardless of how many iDevices there are. Network Operators have seen spikes during Apple OS releases since they started. The only leeway I'll give you is that the original iPhone only supported 802.11b. With .11n and someday .11ac, the ability for these devices to consume data at a faster rate is also increasing. This isn't a new phenomenon. I realize some of you are too cool for Apple Lame low ball remark, however I thought it was the opposite, Apple==coolness? This was in no way meant to be a lowball remark. But it doesn't take much searching to find people exclaiming how they have zero Apple devices or how they don't pay attention to Apple's iJunk. I assumed (probably mistakenly) that the lack of knowing this is going to happen roughly 2-3 times a year was due to being 'too cool' to keep up with the stuff Apple puts out. Regards, Jeroen -- Earthquake Magnitude: 5.3 Date: 2013-09-19 17:25:09.350 UTC Location: 19km ESE of Ishikawa, Japan Latitude: 37.0716; Longitude: 140.6495 Depth: 22.22 km | e-quake.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE
I suspect Leber has either a first or last name that starts with na or nan and this poor guy is the victim of auto-complete failure. But this is NANOG, so I expect nothing but jumping to conclusions and overreactions. Thanks for solidifying my expectations! /Ryan On 10/12/2010 11:49 AM, Carlos Martinez-Cagnazzo wrote: BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists to suggest where he/she might be found... -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: harde...@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387
Re: Using /126 for IPv6 router links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: harde...@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktd77sACgkQtuPckBBbXbpI1QCcCHBU8XcxqTAKDy4SbElfpH7L VlYAoMkhFKHPeIAXb3vepXYDLdgVAmFA =H3uZ -END PGP SIGNATURE-
Re: real hardware router VS linux router
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While you could probably build a linux router that is just as fast as a real hardware router, you're always going to run into the moving pieces part of the equation. In almost all scenarios, moving parts are more prone to failure than non-moving parts. Regardless of what you find out in your research, consider the above in your cost-benefit analysis. /Ryan Deric Kwok wrote: Hi All Actually, what is the different hardware router VS linux router? Have you had experience to compare real router eg: cisco VS linux router? eg: streaming speed... tcp / udp Thank you for your information - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: harde...@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmdbpcACgkQtuPckBBbXboREgCguTikt2UwEIRHNfoNzASreLD/ YLcAoKdr/Gbw8CQuY9dTitvGQdD3+H0s =bsHP -END PGP SIGNATURE-
Re: Inauguration streaming traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We're seeing more TCP1935 than UDP8247. http://ct-mail.cites.uiuc.edu/~hardenrm/graphs/Peakflow-1.png /Ryan Harry Hoffman wrote: Yep, most seems to be port 8247. Which seems to be CNN streaming service. And yay for the p2p options now in flash... nothing like that to make it look like a comp'd system/attack. --Harry On Tue, 2009-01-20 at 12:24 -0500, Patrick Muldoon wrote: On Jan 20, 2009, at 12:20 PM, Jay Hennigan wrote: We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? We are seeing about 150% increase in traffic as well. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C I'm sorry a pentium won't do, you need an SGI to connect with us. - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: harde...@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkl2D9IACgkQtuPckBBbXbrcdwCgoI8sF0fNPK3J983bgRL7h9OI Cy0An3WuZB9sd5ncIrKSeqGOKy+PiOnO =apAL -END PGP SIGNATURE-
Re: Querstions about COGENT and their services...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Overall Cogent has been okay. We've had a few issues over the last several months. One specifically bothersome as it cropped up several times. They basically kept rewriting their CoPP ACLs and kept dropping my side of the /30 from the allow list. This caused our BGP session to start flapping. Each time this happened it took several hours to escalate to someone that understood the problem and could get it fixed. Not even referencing old tickets would help their first line of Support. On one call an engineer told me BGP was flapping because my config was split into address-family ipv4/ipv6 unicast/multicast rather than one big router bgp stanza. We have a session with ATT, so when Cogent does something stupid, we aren't off the net... Other than bidding for a contract in a building they didn't actually have any resources, then trying to get us to pay for the costs of building out there after they wonAnd the sales rep quitting right after they won the RFPthey've been decent. /Ryan Greg VILLAIN wrote: | | On Jun 3, 2008, at 6:06 PM, TS Glassey wrote: | So at one time Cogent was one of the lowest performing bandwidth | providers. Anyone have any responses to their current operations? | | regards, | Todd Glassey CISM CIFI | Chief Scientist/Founder - Certichron Inc | [EMAIL PROTECTED] | 650-796-8178 | | | | Couple remarks on their reputation in europe, I've never had Cogent | transit, so this requires further investigation. | They're the cheapest (cost-wise, I wouldn't venture to say | technically-wise) in Europe, that's a fact. | They often get into peering clashes against major actors, they've | recently been in that situation with Telia, in the past with France's | incumbent (Orange), Level 3 has also depeered them in the past, this is | due to them being brokers and is inherent to their pricing policy - it | certainly will keep happening to them in the future. | The above point is from my perspective a show-stopper, but a good | strategy I've very often heard from some of their customers is to use | them to forward traffic towards exotic locations, where QoS is not an | issue, or where revenue is not critical. | Their IP core is supposedly a patch-work resulting from their numerous | past acquisitions (PSINet, Lambdanet to name a few), which can explain | the many outages they have. | Still, the sales people in Europe are really kind, comprehensive and | caring people, which makes it a little better, I suppose :) | Hope this helped. | | Greg VILLAIN | Independant internet architect - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: [EMAIL PROTECTED] Urbana, IL 61801 University of Illinois - Urbana/Champaign ~ - All your Base - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRZoftuPckBBbXboRAlJ6AJ0aoeBv/xrzr/rPkIqKSIpwGuHwQQCgz0N8 b0q2Lag9Z5a5OpxPoKINzHQ= =ARib -END PGP SIGNATURE-
