Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
On 11/20/22 19:02, Abraham Y. Chen wrote: Dear Mark: 0) I am surprised at your apparently sarcastic opinion. 1) The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development, IETF does not need be involved. Especially, its first step of disabling one line of existing networking program code empowers any party to begin deploying EzIP stealthily for mitigating the IPv4 address pool depletion issues. Note that EzIP is a generic solution applicable to everyone, not limited to Africa. 2) Of course, constructive criticism is always appreciated. However, unspecific comments that confuse and distract the readers only provide dis-service to those disadvantaged population who are enduring the handicaps of being the late-comers to the Internet. My comment was not directed at you. Sorry. I have nothing against the EzIP proposal. It just does not add any real value in solving the IPv4 depletion problem for the amount of effort required to implement it, in my view. I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. Mark.
Re: Alternative Re: ipv4/25s and above
If I had a dollar for every person who has lived their entire life in a high-income western country (US, Canada, western Europe, etc) and has zero personal experience in developing-nation telecom/ISP operations and their unique operational requirements, yet thinks they've qualified to offer an opinion on it... People should go look at some of the WISPs in the Philippines for an example of ISPs building last and middle mile infrastructure on extremely limited budgets. Or really just about anywhere else where the residential broadband market has households where the entire household monthly income is the equivalent of $500 USD. On Sat, 19 Nov 2022 at 04:59, Mark Tinka wrote: > > > On 11/19/22 05:50, Abraham Y. Chen wrote: > > > Dear Owen: > > > > 1) "... Africa ... They don’t really have a lot of alternatives. ...": > > Actually, there is, simple and in plain sight. Please have a look at > > the below IETF Draft: > > It's most amusing, to me, how Africa needs to be told how to be... > > Some folk just can't help themselves. > > Mark. >
Re: Alternative Re: ipv4/25s and above Re: 202211201503.AYC
Dear Rubens: 0) Very good question. It is right to the point! 1) Initially, we thought that we were doing conventional protocol development engineering that was triggered by our curiosity about why IPv4 address pool was depleted. So, IETF Draft was the natural place to report what we were doing. 2) As time went on, it became evident that our scheme was rather unorthodox. That is, it was surprisingly simpler than any other known techniques. As well, the benefits were more and better than we could have dreamed for. At the same time, developed countries such as US where I was in, were not in any material need for IPv4 addresses, yet promoting IPv6. Not being able to sort out this contradiction, it was necessary to keep a continuous public record as IETF Draft revisions of EzIP evolution as we continued to refine our scheme which had turned into a concise system engineering solution, or almost appeared to be a marketing trick. 3) In a sense, we have been purposely publishing our work on the web (beyond IETF Draft) to invite critiques. So far, we have not received any explicit feedback pointing to its flaws, while there have been more than a couple subtle confirmations from rather senior Internet experts. I am sure that you would understand that we can not disclose the latter on our own. Nevertheless, they do enforce our confidence in the EzIP plan. 4) In anticipation of your next question, I would like to add the following. To be sure that our discovery is protected from being claimed by others and then its fair use discouraged, the essence of the EzIP concept was submitted to US Patent Office and has been granted with US Pat. No. 11,159,425. This assures that EzIP may be openly discussed to reach as much general public as possible. Hope the above background recap is sufficient to clear your concerns. I look forward to our additional exchanges. Regards, Abe (2022-11-20 17:00 EST) On 2022-11-20 13:41, Rubens Kuhl wrote: On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen wrote: Dear Mark: 0) I am surprised at your apparently sarcastic opinion. 1) The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development, IETF does not need be involved. If IETF does not need to be involved, why have you submitted 12 versions of your Internet draft to IETF ? https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ Rubens -- This email has been checked for viruses by Avast antivirus software. www.avast.com
Re: Alternative Re: ipv4/25s and above
On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen wrote: > Dear Owen: > > 1) "... Africa ... They don’t really have a lot of alternatives. ...": > Actually, there is, simple and in plain sight. Please have a look at the > below IETF Draft: > > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space Hi Abraham, I know I'm not the sharpest tool in the shed, but I'm having some trouble understanding the deployment model for EzIP. Perhaps you could help clear it up for me? A non-EzIP web server is only going to see the global destination IP address and TCP port number as the unique session identifiers for communication, so the vast amount of additional IP space you postulate existing behind the SPR functionally collapses down into the 64K TCP port range available today in traditional port-based NAT setups. As long as the top 50 websites aren't EzIP-aware, there appears to be no benefit for an ISP to deploy EzIP, because it doesn't actually gain them anything beyond what existing CG-NAT devices already provide as far as their web-browsing customer base is concerned. Most of their communication will still be port-based-NAT, with all the headaches and restrictions inherent in that. And for the top 50 websites, there's a lot of expense and absolutely no upside involved in deploying EzIP. They don't care about how much IP space you have behind your NAT device, and whether it's uniquely identifiable within your local realm; it's not information they can access for tracking users, as they don't know what your internal mapping is, so they'll continue to rely on browser cookies and the like for tracking actual user sessions, regardless of the IP addressing format being used. So, you've got a model where there's functionally almost no benefit to the end user until the major websites start deploying EzIP-aware infrastructure, and there's pretty much no incentive for major websites to spend money upgrading their infrastructure to support EzIP, because it provides no additional benefit for them. This is pretty much exactly the same conundrum that IPv6 faced (and still faces today). I don't see why EzIP is any better than IPv6 or CG-NAT in terms of solving the IPv4 address shortage problem, and it seems to involve more expense for web providers, because it requires them to deploy additional SPR mapping routers into their infrastructure in order to use it, with essentially no additional benefit. Is there a piece to the picture I'm not understanding correctly? Thanks! Matt
Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen wrote: > > Dear Mark: > > 0) I am surprised at your apparently sarcastic opinion. > > 1) The EzIP proposal as referenced by my last MSG is the result of an > in-depth system engineering effort. Since the resultant schemes do not > rely on any protocol development, IETF does not need be involved. If IETF does not need to be involved, why have you submitted 12 versions of your Internet draft to IETF ? https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ Rubens
Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
Dear Mark: 0) I am surprised at your apparently sarcastic opinion. 1) The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development, IETF does not need be involved. Especially, its first step of disabling one line of existing networking program code empowers any party to begin deploying EzIP stealthily for mitigating the IPv4 address pool depletion issues. Note that EzIP is a generic solution applicable to everyone, not limited to Africa. 2) Of course, constructive criticism is always appreciated. However, unspecific comments that confuse and distract the readers only provide dis-service to those disadvantaged population who are enduring the handicaps of being the late-comers to the Internet. Regards, Abe (2022-11-20 12:02 EST) On 2022-11-19 07:58, Mark Tinka wrote: On 11/19/22 05:50, Abraham Y. Chen wrote: Dear Owen: 1) "... Africa ... They don’t really have a lot of alternatives. ...": Actually, there is, simple and in plain sight. Please have a look at the below IETF Draft: It's most amusing, to me, how Africa needs to be told how to be... Some folk just can't help themselves. Mark. -- This email has been checked for viruses by Avast antivirus software. www.avast.com
Re: afrinic rpki issue
Hi Job, Thank you for this good analysis and for sharing your findings. The issue has since been fixed and the team will publish a post-mortem accordingly once we are done with making sure the issue will not reappear. Your recommendation is well noted and I cc my colleague so that they can take that into consideration in our improvement roadmap. Best regards, == Cedrick Adrien MBEYET Ebene Cybercity, Mauritius +230 5851 7674 +++ Never give up, Keep moving forward +++ On Sun, Nov 20, 2022 at 3:49 PM Job Snijders via NANOG wrote: > Hi all, > > It appears PacketVis correctly identified an issue. > > AFRINIC's self-signed root AfriNIC.cer [1] points via its SIA to > 'afrinic-ca.cer' [2] which in turn references a RPKI Manifest named > 'K1eJenypZMPIt_e92qek2jSpj4A.mft'. > > The K1eJenypZMPIt_e92qek2jSpj4A Manifest lists 499 Certificate > Authorities. This Manifest represents the demarcation point between > "Afrinic as root CA operator" and "Afrinic hosting rpki on behalf of its > members". In other words; this is an important top-level Manifest in the > critical path towards the ROAs of the Afrinic members. > > There was a ~ 7 hour gap in the validity window of this Manifest and its > companion CRL (from 20221120T000311Z until 20221120T071514Z). The > serials 1E19 and 1E1A (respectively 12B2 and 12B3) are successive. > > rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.crl > CRL Serial Number:1E19 > CRL valid since: Nov 18 00:03:11 2022 GMT > CRL valid until: Nov 20 00:03:11 2022 GMT > > CRL Serial Number:1E1A > CRL valid since: Nov 20 07:15:12 2022 GMT > CRL valid until: Nov 22 07:15:12 2022 GMT > > rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.mft > Manifest Number: 12B2 > Manifest valid since: Nov 18 00:03:13 2022 GMT > Manifest valid until: Nov 20 00:03:13 2022 GMT > > Manifest Number: 12B3 > Manifest valid since: Nov 20 07:15:14 2022 GMT > Manifest valid until: Nov 22 07:15:14 2022 GMT > > (The above can be reconstructed using archives from > http://www.rpkiviews.org) > > The rcynic validator hosted at Afrinic also noticed a gap in objects: > https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net_week_svg.html > > A possible recommendation might be to increase the validity window of > these two objects from a sliding 48-hour window to a 1 or 2 week window. > This way any stalling in the issuance process wouldn't case operational > issues on the weekend. > > Kind regards, > > Job > > [1]: SKI EB:68:0F:38:F5:D6:C7:1B:B4:B1:06:B8:BD:06:58:50:12:DA:31:B6 > [2]: SKI 2B:57:89:7A:7C:A9:64:C3:C8:B7:F7:BD:DA:A7:A4:DA:34:A9:8F:80 > > > > On Sat, Nov 19, 2022 at 08:36:23PM -0800, Randy Bush wrote: > > From: PacketVis > > Date: Sun, 20 Nov 2022 04:30:44 + > > > > Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs > disappeared from afrinic > > > > See more details about the event: > > > https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613 >
Re: afrinic rpki issue
Hi all, It appears PacketVis correctly identified an issue. AFRINIC's self-signed root AfriNIC.cer [1] points via its SIA to 'afrinic-ca.cer' [2] which in turn references a RPKI Manifest named 'K1eJenypZMPIt_e92qek2jSpj4A.mft'. The K1eJenypZMPIt_e92qek2jSpj4A Manifest lists 499 Certificate Authorities. This Manifest represents the demarcation point between "Afrinic as root CA operator" and "Afrinic hosting rpki on behalf of its members". In other words; this is an important top-level Manifest in the critical path towards the ROAs of the Afrinic members. There was a ~ 7 hour gap in the validity window of this Manifest and its companion CRL (from 20221120T000311Z until 20221120T071514Z). The serials 1E19 and 1E1A (respectively 12B2 and 12B3) are successive. rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.crl CRL Serial Number:1E19 CRL valid since: Nov 18 00:03:11 2022 GMT CRL valid until: Nov 20 00:03:11 2022 GMT CRL Serial Number:1E1A CRL valid since: Nov 20 07:15:12 2022 GMT CRL valid until: Nov 22 07:15:12 2022 GMT rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.mft Manifest Number: 12B2 Manifest valid since: Nov 18 00:03:13 2022 GMT Manifest valid until: Nov 20 00:03:13 2022 GMT Manifest Number: 12B3 Manifest valid since: Nov 20 07:15:14 2022 GMT Manifest valid until: Nov 22 07:15:14 2022 GMT (The above can be reconstructed using archives from http://www.rpkiviews.org) The rcynic validator hosted at Afrinic also noticed a gap in objects: https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net_week_svg.html A possible recommendation might be to increase the validity window of these two objects from a sliding 48-hour window to a 1 or 2 week window. This way any stalling in the issuance process wouldn't case operational issues on the weekend. Kind regards, Job [1]: SKI EB:68:0F:38:F5:D6:C7:1B:B4:B1:06:B8:BD:06:58:50:12:DA:31:B6 [2]: SKI 2B:57:89:7A:7C:A9:64:C3:C8:B7:F7:BD:DA:A7:A4:DA:34:A9:8F:80 On Sat, Nov 19, 2022 at 08:36:23PM -0800, Randy Bush wrote: > From: PacketVis > Date: Sun, 20 Nov 2022 04:30:44 + > > Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs > disappeared from afrinic > > See more details about the event: > https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613
Re: afrinic rpki issue
Hi Randy, Thank you for sharing this information. Our team is investigating the alert. Best regards, == Cedrick Adrien MBEYET Ebene Cybercity, Mauritius +230 5851 7674 +++ Never give up, Keep moving forward +++ On Sun, Nov 20, 2022 at 8:37 AM Randy Bush wrote: > From: PacketVis > Date: Sun, 20 Nov 2022 04:30:44 + > > Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs > disappeared from afrinic > > See more details about the event: > > https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613 >
