All Slides

Proposal of an extended CYPHONIC adapter supporting general nodes using virtual IPv6 addresses

埋め込みコード

iframe
<iframe src="https://www.ren510.dev/slides/embed/proposal-of-an-extended-cyphonic-adapter-supporting-general-nodes-using-virtual-ipv6-addresses/" title="Proposal of an extended CYPHONIC adapter supporting general nodes using virtual IPv6 addresses" width="100%" style="aspect-ratio:1.778" frameborder="0" allow="clipboard-write" allowfullscreen></iframe>
script タグ
<script defer class="ren510-slide-embed" data-slug="proposal-of-an-extended-cyphonic-adapter-supporting-general-nodes-using-virtual-ipv6-addresses" data-ratio="1.7777777777777777" src="https://www.ren510.dev/static/slides/embed.js"></script>
🤖 AI による要約 ✨
  1. P.1 — Title slide. GCCE 2022 presentation on extending CYPHONIC adapter to support general nodes with virtual IPv6 addresses.
  2. P.2 — Presentation outline covering network/security, CYPHONIC concept, conventional systems, objective, proposal, evaluation, and conclusions.
  3. P.3 — Modern network usage patterns. Increasing diversity and complexity including cloud, IoT cooperation, and device mobility.
  4. P.4 — Zero-trust security approach and issues. NAPT/IP version differences and device movement make secure end-to-end communication challenging.
  5. P.5 — CYPHONIC concept. Secure end-to-end communication framework supporting inter-connectivity, seamless mobility, and zero-trust security.
  6. P.6 — Conventional CYPHONIC systems. General nodes (IoT/embedded devices) cannot install client programs, limiting CYPHONIC adoption.
  7. P.7 — Issues of conventional CYPHONIC adapter. Only supported virtual IPv4 addresses, unable to handle IPv6 address space.
  8. P.8 — Research objective. Proposal of dual stack CYPHONIC adapter supporting both IPv4 and IPv6 virtual IP addresses.
  9. P.9 — Components of CYPHONIC. Cloud services (AS/NMS/TRS), CYPHONIC node, CYPHONIC adapter, and general node roles.
  10. P.10 — Processing functions in conventional adapter. Signaling Module, Packet Handling Module, and General Node Management Module.
  11. P.11 — System model of conventional CYPHONIC adapter. Management and communication function architecture with real interfaces.
  12. P.12 — Requirements for proposed adapter. IPv6 router functionality and DHCPv6 server functionality using NDP and stateful DHCPv6.
  13. P.13 — Processing functions in new adapter. Addition of NDP, DHCPv6 mechanism, DNS server, Router Configuration, and Address Configuration modules.
  14. P.14 — System model of new CYPHONIC adapter. Extended architecture with Host Configuration, Local DNS Service, and CYPHONIC Resolver.
  15. P.15 — Sequence of getting general node information. Authentication, registration, and extended signaling to obtain MAC/VIP/FQDN.
  16. P.16 — Sequence of general node configuration. NDP process, stateful DHCPv6 for virtual IP assignment, and registration for general node.
  17. P.17 — Sequence of overlay network communication. Route selection, tunnel establishment, ND proxy process, and communication via overlay network.
  18. P.18 — Performance evaluation setup. Measuring packet processing time and signaling processing time on Raspberry Pi 4 Model B.
  19. P.19 — Processes to be evaluated. DNS response time and NDP response time measuring initial communication delay.
  20. P.20 — Delay time results. IPv6 adapter achieved 23.57ms vs IPv4 adapter 28.00ms. Route selection 14.21ms vs 19.74ms improvement.
  21. P.21 — Communication performance results. Proposed IPv6 system showed equivalent throughput and round-trip time to conventional IPv4 system.
  22. P.22 — Conclusions. Extended CYPHONIC adapter supports both IPv4/IPv6 in one adapter with IPv6 mechanism-based general node configuration.
  23. P.23 — Q&A slide.
  24. P.24 — Supplementary: Perimeter security model vs zero-trust security model comparison.
  25. P.25 — Supplementary: Requirements for zero-trust security. Direct device connections needed for secure end-to-end communication.
  26. P.26 — Supplementary: Processing functions in CYPHONIC node. Signaling, CYPHONIC Resolver, and Packet Handling modules.
  27. P.27 — Supplementary: System model of CYPHONIC node. Application, CYPHONIC Daemon, virtual interface, and real interface architecture.
  28. P.28 — Supplementary: DNS packet processing. Local DNS server handles general domains, CYPHONIC Resolver handles CYPHONIC domains.
  29. P.29 — Supplementary: Difference in processing methods between CYPHONIC node and general node via adapter.
  30. P.30 — Supplementary: Detailed system model of CYPHONIC node with Domain Filter, Mobility Management, and Packet Hook.
  31. P.31 — Supplementary: Detailed system model of conventional CYPHONIC adapter with DHCPv4 address configuration.
  32. P.32 — Supplementary: Detailed system model of new CYPHONIC adapter with Host Configuration and Router Configuration.
  33. P.33 — Supplementary: Comparison of conventional technologies (STUN, ICE, Mobile IPv4, DSMIPv6) vs CYPHONIC for inter-connectivity and mobility.
  34. P.34 — Supplementary: Overview of CYPHONIC overlay network with AS authentication and NMS network info registration.
  35. P.35 — Supplementary: CYPHONIC overview showing Application Layer and CYPHONIC Layer with virtual IP communication.
  36. P.36 — Supplementary: PDU flow in CYPHONIC. Application layer to network layer encapsulation with real IP and virtual IP.
  37. P.37 — Supplementary: Authentication process. SSL/TLS-based login, certification, and common key generation stored in DB.
  38. P.38 — Supplementary: Registration process. Sending network information to NMS and retrieving virtual IP address from DB.
  39. P.39 — Supplementary: Route selection process. FQDN-based path search, Tunnel Key generation, and communication path distribution.
  40. P.40 — Supplementary: Route selection process via TRS. Tunnel Key and Temp Key generation with relay request to TRS.
  41. P.41 — Supplementary: Tunnel establishment process. End Key generation and distribution via Tunnel Request encrypted with Tunnel Key.
  42. P.42 — Supplementary: Tunnel establishment via TRS. End Key encrypted with Temp Key and relayed through TRS.