DOCSLIB.ORG

Appendix a Solutions to Selected Exercises

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Appendix a Solutions to Selected Exercises Appendix A Solutions to Selected Exercises Overview There are a few things you should keep in mind: 1. Networking problems sometimes have multiple correct solutions. Given is one solution and there may be others that are equally correct. 2. If there is a mistake in the solution, please check the website for errata, double– check your work and discuss it with a local expert. 3. If you have need of an additional solution and the steps above have not helped (or you can’t find a solution anywhere) you may contact me for a solution as long as you keep in mind I may not respond quickly or at all. Do not take this as a rejection, but rather as a sign I am having a delay getting to your request. I will eventually respond, I hope. This appendix will give the solutions to some exercises in this book. At some point there may be additional solutions on line at https://www.springer.com/us/book/ 9783030344955 and www.gerryhowser.com/book/9783030344955/solutions, both of which are under construction at the time of this writing. © Springer Nature Switzerland AG 2020 425 G. Howser, Computer Networks and the Internet, https://doi.org/10.1007/978-3-030-34496-2 Appendix B Request For Comments The RFCs below are relevant to this book. This is not an exhaustive list and most RFCs are typically dense and hard to read. Normally RFCs are most useful when writing a process to implement a specific protocol. AppleTalk AppleTalk Title RFC 1378 The PPP AppleTalk Control Protocol (ATCP) RFC 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing RFC 6281 UnderstandingApple’sBack to My Mac (BTMM) Service RFC 6760 Requirementsfor a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) ARP ARP Title RFC 1027 Using ARP to implementtransparentsubnetgateways RFC 1293 Inverse Address Resolution Protocol RFC1390 TransmissionofIPandARPoverFDDINetworks RFC 1577 Classical IP and ARP over ATM RFC 1931 Dynamic RARP Extensionsfor Automatic Network Address Acquisition RFC 5494 IANA Allocation Guidelinesfor the Address Resolution Protocol (ARP) © Springer Nature Switzerland AG 2020 427 G. Howser, Computer Networks and the Internet, https://doi.org/10.1007/978-3-030-34496-2 428 B Request For Comments ATM ATM Title RFC 1483 MultiprotocolEncapsulation overATM Adaptation Layer 5 RFC 1577 Classical IP and ARP over ATM RFC1680 IPngSupportforATMServices RFC 5828 Generalized MultiprotocolLabel Switching (GMPLS) Ethernet Label Switching Architecture and Framework Babel Babel Title RFC6126 TheBabelRoutingProtocol RFC 7298 Babel Hashed Message AuthenticationCode (HMAC) Cryptographic Authentication RFC 7557 ExtensionMechanismfor the Babel RoutingProtocol BGP BGP Title RFC1266 ExperiencewiththeBGPProtocol RFC1267 BorderGatewayProtocol3(BGP-3) RFC 1322 A UnifiedApproachtoInter-DomainRouting RFC 1364 BGP OSPF Interaction RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC 1403 BGP OSPF Interaction RFC 1520 ExchangingRouting InformationAcross ProviderBoundaries in the CIDR Environment RFC 2842 Capabilities Advertisement with BGP-4 RFC2858 MultiprotocolExtensionsforBGP-4 RFC4893 BGP SupportforFour-octetASNumberSpace RFC 5396 TextualRepresentationof AutonomousSystem (AS) Numbers RFC 6811 BGP Prefix Origin Validation RFC 8388 Usage andApplicabilityof BGP MPLS-Based Ethernet VPN RFC 8416 Simplified Local InternetNumber Resource Management with the RPKI (SLURM) RFC 8503 BGP/MPLS Layer3 VPN Multicast ManagementInformation Base RFC 8571 BGP - Link State(BGP-LS) Advertisementof IGPTraffic Engineering Performance Metric Extensions B Request For Comments 429 BOOTP BOOTP Title RFC 0906 Bootstrap loading using TFTP RFC 0951 BOOTSTRAP PROTOCOL (BOOTP) RFC 1395 BOOTP VendorInformationExtensions RFC 1497 BOOTP VendorInformationExtensions RFC 1532 Clarifications and Extensions for the Bootstrap Protocol RFC 1533 DHCP OptionsandBOOTPVendorExtensions RFC 1542 Clarifications and Extensions for the Bootstrap Protocol RFC 2132 DHCP OptionsandBOOTPVendorExtensions CIDR CIDR Title RFC 1517 Applicability Statement for the Implementationof Classless Inter-Domain Routing (CIDR) RFC 1518 An Architecturefor IPAddressAllocationwith CIDR RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC 1520 ExchangingRouting InformationAcross ProviderBoundaries in the CIDR Environment RFC1812 RequirementsforIPVersion4Routers RFC 1817 CIDR and Classful Routing RFC 1917 An Appealto the InternetCommunityto Return Unused IP Networks (Prefixes) to the IANA RFC2036 Observationsontheuse ofComponentsoftheClass A Address Space within the Internet RFC 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan RFC 7608 IPv6 Prefix Length Recommendationfor Forwarding DDNS DDNS Title RFC 4703 Resolution of Fully Qualified DomainName (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients RFC 7393 Using the PortControlProtocol(PCP) to UpdateDynamic DNS 430 B Request For Comments Default route default Title RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC2461 NeighborDiscoveryforIPVersion6(IPv6) RFC 4191 Default Router Preferencesand More-SpecificRoutes DHCP DHCP Title RFC 0951 BOOTSTRAP PROTOCOL (BOOTP) RFC 1497 BOOTP VendorInformationExtensions RFC 1532 Clarifications and Extensions for the Bootstrap Protocol RFC 1533 DHCP OptionsandBOOTPVendorExtensions RFC1541 DynamicHost ConfigurationProtocol RFC 1542 Clarifications and Extensions for the Bootstrap Protocol RFC2131 DynamicHost ConfigurationProtocol RFC 2132 DHCP OptionsandBOOTPVendorExtensions RFC3046 DHCP RelayAgentInformationOption RFC 3315 DynamicHost ConfigurationProtocolfor IPv6(DHCPv6) RFC 3396 EncodingLongOptionsin the DynamicHostConfiguration Protocol (DHCPv4) RFC 3646 DNS Configurationoptionsfor DynamicHost Configuration Protocol for IPv6 (DHCPv6) RFC 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 RFC 4361 Node-specificClient Identifiersfor DynamicHost Configuration Protocol Version Four (DHCPv4) RFC 4701 A DNS ResourceRecord(RR) forEncodingDynamicHost Configuration Protocol (DHCP) Information (DHCID RR) RFC 4702 The DynamicHost ConfigurationProtocol(DHCP) Client Fully Qualified Domain Name (FQDN) Option RFC 4703 Resolution of Fully Qualified DomainName (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients RFC 6842 Client Identifier Option in DHCP Server Replies RFC 7969 Customizing DHCP Configuration on the Basis of Network Topology RFC 8026 Unified IPv4-in-IPv6Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism RFC 8115 DHCPv6 OptionforIPv4-EmbeddedMulticast and Unicast IPv6 Prefixes B Request For Comments 431 DHCP Title RFC 8353 Generic Security Service API Version 2: Java Bindings Update RFC 8415 DynamicHost ConfigurationProtocolfor IPv6(DHCPv6) RFC 8539 Softwire Provisioning Using DHCPv4 over DHCPv6 DNS DNS Title RFC0799 InternetNameDomains RFC0882 DOMAINNAMES-CONCEPTSandFACILITIES RFC0883 DOMAINNAMES-IMPLEMENTATIONand SPECIFICATIONS RFC0973 DOMAINNAMES-IMPLEMENTATIONand SPECIFICATIONS RFC0974 Mailroutingandthedomainsystem RFC1034 DOMAINNAMES-CONCEPTSandFACILITIES RFC 1035 Domain names- implementationandspecification RFC1101 DNSEncodingofNetworkNamesandOtherTypes RFC1178 ChoosingaNameforYourComputer RFC 1183 New DNS RR Definitions RFC1348 DNSNSAPRRs RFC 1591 Domain NameSystem Structureand Delegation RFC1637 DNSNSAPResourceRecords RFC1706 DNSNSAPResourceRecords RFC1794 DNSSupportforLoadBalancing RFC 1876 A MeansforExpressingLocationInformationin theDomain Name System RFC 1912 CommonDNS OperationalandConfigurationErrors RFC 1918 AddressAllocationfor Private Internets RFC1982 SerialNumberArithmetic RFC1995 IncrementalZoneTransferinDNS RFC 1996 A MechanismforPromptNotificationofZoneChanges(DNS NOTIFY) RFC 2065 DomainNameSystemSecurityExtensions RFC2136 DynamicUpdatesin theDomainNameSystem(DNS UPDATE) RFC2137 SecureDomainNameSystem DynamicUpdate RFC 2181 Clarifications to the DNS Specification RFC2230 KeyExchangeDelegationRecordfortheDNS RFC 2308 NegativeCachingofDNS Queries(DNSNCACHE) RFC 2317 Classless IN-ADDR.ARPA delegation RFC 2535 DomainNameSystemSecurityExtensions RFC2536 DSAKEYsandSIGsintheDomainNameSystem(DNS) 432 B Request For Comments DNS Title RFC 2539 Storageof Diffie-HellmanKeysin theDomainNameSystem (DNS) RFC 2540 Detached DomainName System (DNS) Information RFC2606 ReservedTopLevelDNSNames RFC2671 ExtensionMechanismsforDNS(EDNS0) RFC2672 Non-TerminalDNS NameRedirection RFC2673 BinaryLabelsintheDomainNameSystem RFC 2694 DNS extensionsto Network Address Translators(DNS ALG) RFC2782 A DNSRRforspecifyingthelocationofservices(DNS SRV) RFC 2845 Secret Key Transaction Authenticationfor DNS (TSIG) RFC 2874 DNS Extensionsto SupportIPv6 Address Aggregation and Renumbering RFC2930 SecretKeyEstablishmentforDNS(TKEYRR) RFC 3007 SecureDomainNameSystem (DNS) DynamicUpdate RFC3110 RSA/SHA-1SIGsandRSA KEYsintheDomainName System (DNS) RFC3123 ADNSRRTypeforListsofAddressPrefixes(APLRR) RFC 3363 Representing InternetProtocolversion 6 (IPv6)Addresses in the Domain Name System (DNS) RFC 3401 DynamicDelegation DiscoverySystem (DDDS) Part One: The Comprehensive DDDS RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm RFC 3403 DynamicDelegation DiscoverySystem (DDDS) Part Three: The Domain Name System (DNS) Database RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) RFC 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures RFC3425
Load more

Recommended publications
  • Symbols Numerics A
    I N D E X GLOP, 484–485 Symbols IP multicast, 480 limited-scope, 484 ! (exclamation point) character, 105 MAC address notification, 317–318 # (pound sign) character, 105 NAT, 649 reserved link local, 483–484 Numerics source-specific multicast, 484 virtual MAC, 573 10-Gigabit, 54 adjacencies, 393–394, 408 10-Mbps Ethernet, 48 ADSL (asymmetric digital subscriber line), 56 802.1D, compatibility with RSTP, 230 agents, relay (DHCP), 379 802.1Q, 156–158 aggregate policers, 448 802.1X Aggressive mode UDLD (A-UDLD), 336–338, 604 configuration exercise, 663–669 configuration exercises, 354 network access security, 639–641 versus Loop Guard, 272 AppleTalk Remote, 624 applications A Auto QoS, 463 Cisco AVVID, 16 AAA statistics, 291 accounting, 625, 629 voice, 596 authentication, 173, 623–626 Application-Specific Integrated Circuits. See ASICs authorization, 624, 627 applying RACLs, 643 configuration exercise, 663–669 Architecture for Voice, Video and integrated Data. configuring, 630–631 See Cisco AVVID aaa authentication login command, 626 ARP (Address Resolution Protocol), 12 aaa new-model command, 87, 626 DAI, 654–658 access as a security feature, 658–659 firewalls, 647–648 throttling, 396–398 hopping attacks (VLAN), 660–661 ASICs (Application-Specific Integrated Circuits), physical, 619 5–6, 275 unauthorized, 77 assured forwarding, 431–432 access control lists. See ACLs asymmetric digital subscriber line (ADSL), 56 access layer, 18 attacks, 655, 660–661 access-layer switches, 50 attenuation, 720 accounting, 625, 629 A-UDLD (Aggressive mode UDLD), ACLs (access control lists), 4, 618, 643 336–338, 604 PACLs, 646 configuration exercises, 354 RACLs, 643 versus Loop Guard, 272 security, 642 authentication, 173, 623–626 VACLs, 644 authorization, 624, 627 vty lines, 619 auth-proxy, 627 active keyword, 513 Auto QoS, 463 adding switches, 186 auto-negotiation, 53, 767 Address Resolution Protocol.
    [Show full text]
  • CEH: Certified Ethical Hacker Course Content
    CEH: Certified Ethical Hacker Course ID #: 1275-100-ZZ-W Hours: 35 Course Content Course Description: The Certified Ethical Hacker (CEH) program is the core of the most desired information security training system any information security professional will ever want to be in. The CEH, is the first part of a 3 part EC-Council Information Security Track which helps you master hacking technologies. You will become a hacker, but an ethical one! As the security mindset in any organization must not be limited to the silos of a certain vendor, technologies or pieces of equipment. This course was designed to provide you with the tools and techniques used by hackers and information security professionals alike to break into an organization. As we put it, “To beat a hacker, you need to think like a hacker”. This course will immerse you into the Hacker Mindset so that you will be able to defend against future attacks. It puts you in the driver’s seat of a hands-on environment with a systematic ethical hacking process. Here, you will be exposed to an entirely different way of achieving optimal information security posture in their organization; by hacking it! You will scan, test, hack and secure your own systems. You will be thought the Five Phases of Ethical Hacking and thought how you can approach your target and succeed at breaking in every time! The ve phases include Reconnaissance, Gaining Access, Enumeration, Maintaining Access, and covering your tracks. The tools and techniques in each of these five phases are provided in detail in an encyclopedic approach to help you identify when an attack has been used against your own targets.
    [Show full text]
  • Configurable Routing in Ad-Hoc Networks
    Configurable Routing in Ad-Hoc Networks Nadine Shillingford and Christian Poellabauer Department of Computer Science and Engineering University of Notre Dame Notre Dame, IN 46556 fnshillin, [email protected] Abstract— The actual use of a wireless ad-hoc network or run across the network, will be unknown a-priori. Further, ad- its operational parameters may be unknown before deployment hoc networks may be accessed by varying numbers of clients or they may change during the life time of a network. This (users), with different applications and differing expectations requires that an ad-hoc network be configurable to the unique needs of a client and that multiple clients can configure the on QoS. Therefore, it will be essential to make configurability network simultaneously. The QoS metric(s) used in the selection and customizability of future ad-hoc networks a key design of routes in an ad-hoc routing protocol can strongly affect the feature. network’s performance. Unfortunately, the majority of existing Toward this end, this work introduces the CMR (Con- routing protocols support only one or two fixed metrics in route figurable Mesh Routing) toolkit which provides an easy-to- selection. We conducted a survey of over 40 routing protocols published from 1994-2007 which indicated that 90% of the use API for ad-hoc networks, allowing applications or users protocols use one or two metrics and only 10% use three to to implement their own routing protocols and QoS metrics. four metrics in route selection. Toward this end, we propose a While our prototype implementation supports four of the most modular routing toolkit for ad-hoc networks, where users and popular QoS metrics, it is easily extensible and we expect that applications can initiate route discoveries that best suit their QoS future versions will cover a large variety of QoS metrics.
    [Show full text]
  • CS 638 Lab 6: Transport Control Protocol (TCP)
    CS 638 Lab 6: Transport Control Protocol (TCP) Joe Chabarek and Paul Barford University of Wisconsin –Madison jpchaba,[email protected] The transport layer of the network protocol stack 1 Overview and Objectives (layer 4) sits between applications (layers 5-7) and Unlike prior labs, the focus of lab #6 is is on the network (layer 3 and below). The most basic learning more about experimental tools and on ob- capability that is enabled by transport is multiplex- serving the behavior of the various mechanisms that ing the network between multiple applications that are part of TCP. The reason for this is because in wish to communicate with remote hosts. Similar to moving from layer 3 to layer 4, we are moving away other layers of the network protocol stack, transport from the network per se, and into end hosts. Further- protocols encapsulate packets with their own header more, network administrators usually don’t spend a before passing them down to layer 3 and decapsulate lot of time messing around with TCP since there is packets before passing them up to applications. no programming or management interface to TCP The most simple transport protocol is the User on end hosts. The exception is content providers Datagram Protocol (UDP). UDP provides a mul- who may make tweaks in an attempt to get better tiplexing/demultiplexing capability for applications performance on large file transfers. but not much more. Most significantly, UDP pro- In terms of experimental tools, a focus of this vides no guarantees for reliability, which is unac- lab is on learning about traffic generation.
    [Show full text]
  • Serial/IP COM Port Redirector User Guide
    Navigation: »No topics above this level« Serial/IP® COM Port Redirector User Guide OEM Edition Quick Start Guide Version 4.9 Serial/IP is a registered trademark of Tactical Software, LLC. Tactical Software is a registered trademark of Tactical Software, LLC. Copyright © 2016 Tactical Software, LLC. www.tacticalsoftware.com This Quick Start Guide describes how to install and configure the Serial/IP Redirector so that the Windows applications can use virtual COM ports to access networked serial devices. Configure the Serial Device Server Make sure that the serial server makes its devices available on a TCP port. Install the Serial/IP Software · Log in as Administrator. · Run the Serial/IP setup program. · Use all default choices. · The Serial/IP Redirector will begin running. Windows will not need to be restarted. Create Virtual COM Ports In the Select Ports window, select one or more virtual COM ports, and then click OK. The Serial/IP Select Ports window Configure a Virtual COM Port Enter the IP Address of the serial device server. Enter the TCP Port Number that it is listening on. If the server requires a login, then select the Use Credentials From checkbox. Then in the drop-down list, select Use Credentials Below and enter the Username and Password. The Serial/IP Control Panel Run Auto Configure Click Auto Configure. In the Auto Configure window, click Start. When it completes, click Use Settings. The correct setting will be made for Connection Protocol. The Serial/IP Auto Configure window Ensure that Firewall Software Permits Connections The Serial/IP setup program will add an exception for Serial/IP in the Microsoft Windows Firewall.
    [Show full text]
  • Openswitch OPX Configuration Guide Release 3.0.0 2018 - 9
    OpenSwitch OPX Configuration Guide Release 3.0.0 2018 - 9 Rev. A02 Contents 1 Network configuration....................................................................................................................................4 2 Interfaces...................................................................................................................................................... 5 Physical ports..................................................................................................................................................................... 5 Fan-out interfaces..............................................................................................................................................................6 Port-channel and bond interfaces....................................................................................................................................7 VLAN interfaces................................................................................................................................................................. 7 Port profiles.........................................................................................................................................................................8 3 Layer 2 bridging............................................................................................................................................10 VLAN bridging...................................................................................................................................................................10
    [Show full text]
  • Security Analysis of the Signal Protocol Student: Bc
    ASSIGNMENT OF MASTER’S THESIS Title: Security Analysis of the Signal Protocol Student: Bc. Jan Rubín Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security Department: Department of Computer Systems Validity: Until the end of summer semester 2018/19 Instructions 1) Research the current instant messaging protocols, describe their properties, with a particular focus on security. 2) Describe the Signal protocol in detail, its usage, structure, and functionality. 3) Select parts of the protocol with a potential for security vulnerabilities. 4) Analyze these parts, particularly the adherence of their code to their documentation. 5) Discuss your findings. Formulate recommendations for the users. References Will be provided by the supervisor. prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague January 27, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Computer Systems Master’s thesis Security Analysis of the Signal Protocol Bc. Jan Rub´ın Supervisor: Ing. Josef Kokeˇs 1st May 2018 Acknowledgements First and foremost, I would like to express my sincere gratitude to my thesis supervisor, Ing. Josef Kokeˇs,for his guidance, engagement, extensive know- ledge, and willingness to meet at our countless consultations. I would also like to thank my brother, Tom´aˇsRub´ın,for proofreading my thesis. I cannot express enough gratitude towards my parents, Lenka and Jaroslav Rub´ınovi, who supported me both morally and financially through my whole studies. Last but not least, this thesis would not be possible without Anna who re- lentlessly supported me when I needed it most. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.
    [Show full text]
  • Is Bob Sending Mixed Signals?
    Is Bob Sending Mixed Signals? Michael Schliep Ian Kariniemi Nicholas Hopper University of Minnesota University of Minnesota University of Minnesota [email protected] [email protected] [email protected] ABSTRACT Demand for end-to-end secure messaging has been growing rapidly and companies have responded by releasing applications that imple- ment end-to-end secure messaging protocols. Signal and protocols based on Signal dominate the secure messaging applications. In this work we analyze conversational security properties provided by the Signal Android application against a variety of real world ad- versaries. We identify vulnerabilities that allow the Signal server to learn the contents of attachments, undetectably re-order and drop messages, and add and drop participants from group conversations. We then perform proof-of-concept attacks against the application to demonstrate the practicality of these vulnerabilities, and suggest mitigations that can detect our attacks. The main conclusion of our work is that we need to consider more than confidentiality and integrity of messages when designing future protocols. We also stress that protocols must protect against compromised servers and at a minimum implement a trust but verify model. 1 INTRODUCTION (a) Alice’s view of the conversa-(b) Bob’s view of the conversa- Recently many software developers and companies have been inte- tion. tion. grating end-to-end encrypted messaging protocols into their chat applications. Some applications implement a proprietary protocol, Figure 1: Speaker inconsistency in a conversation. such as Apple iMessage [1]; others, such as Cryptocat [7], imple- ment XMPP OMEMO [17]; but most implement the Signal protocol or a protocol based on Signal, including Open Whisper Systems’ caching.
    [Show full text]
  • Signal E2E-Crypto Why Can’T I Hold All These Ratchets
    Signal E2E-Crypto Why Can’t I Hold All These Ratchets oxzi 23.03.2021 In the next 30 minutes there will be I a rough introduction in end-to-end encrypted instant messaging, I an overview of how Signal handles those E2E encryption, I and finally a demo based on a WeeChat plugin. Historical Background I Signal has not reinvented the wheel - and this is a good thing! I Goes back to Off-the-Record Communication (OTR)1. OTR Features I Perfect forward secrecy I Deniable authentication 1Borisov, Goldberg, and Brewer. “Off-the-record communication, or, why not to use PGP”, 2004 Influence and Evolution I OTR influenced the Signal Protocol, Double Ratchet. I Double Ratchet influence OMEMO; supports many-to-many communication. I Also influenced Olm, E2E encryption of the Matrix protocol. I OTR itself was influenced by this, version four was introduced in 2018. Double Ratchet The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. The Double Ratchet algorithm2 is essential in Signal’s E2E crypto. But first, some basics. 2Perrin, and Marlinspike. “The Double Ratchet Algorithm”, 2016 Cryptographic Ratchet A ratchet is a cryptographic function that only moves forward. In other words, one cannot easily reverse its output. Triple Ratchet, I guess.3 3By Salvatore Capalbi, https://www.flickr.com/photos/sheldonpax/411551322/, CC BY-SA 2.5 Symmetric-Key Ratchet Symmetric-Key Ratchet In everyday life, Keyed-Hash Message Authentication Code (HMAC) or HMAC-based KDFs (HKDF) are used. func ratchet(ckIn[]byte)(ckOut, mk[]byte){ kdf := hmac.New(sha256.New, ckIn) kdf.Write(c) // publicly known constant c out := kdf.Sum(nil) return out[:32], out[32:] } ck0 :=[]byte{0x23, 0x42, ...} // some initial shared secret ck1, mk1 := ratchet(ck0) ck2, mk2 := ratchet(ck1) Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Originally, DH uses primitive residue classes modulo n.
    [Show full text]
  • Etsi Ts 103 443-3 V1.1.1 (2016-08)
    ETSI TS 103 443-3 V1.1.1 (2016-08) TECHNICAL SPECIFICATION Integrated broadband cable telecommunication networks (CABLE); IPv6 Transition Technology Engineering and Operational Aspects; Part 3: DS-Lite 2 ETSI TS 103 443-3 V1.1.1 (2016-08) Reference DTS/CABLE-00018-3 Keywords cable, HFC, IPv6 ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Fbi Fbi Flash
    TLP: GREEN FBI FLASH FBI FBI Liaison Alert System #M-000045-TT The following information was obtained through FBI investigation and is provided in conjunction with the FBI’s statutory requirement to conduct victim notification as outlined in 42 USC § 10607. In furtherance of public-private partnerships, the FBI routinely advises private industry of various cyber threat indicators observed during the course of our investigations. This data is provided in order to help cyber security professionals and systems administrators to guard against the persistent malicious actions of cyber criminals. This product is released at TLP: GREEN. The information in this product is useful for the awareness of all participating organizations as well as with peers within the broader community or sector. Recipients may share this information with peers and partner organizations within their sector or community, but not via publicly accessible channels. SUMMARY The FBI is providing the following information with HIGH confidence: A group of cyber actors utilizing infrastructure located in Iran have been conducting computer network exploitation activity against public and private U.S. organizations, including Cleared Defense Contractors (CDCs), academic institutions, and energy sector companies. The actors typically utilize common computer intrusion techniques such as the use of TOR, open source reconnaissance, exploitation via SQL injection and web shells, and open source tools for further network penetration and persistence. Internet-facing infrastructures, such as web servers, are typical targets for this group. Once the actors penetrate a victim network, the actors exfiltrate network design information and legitimate user credentials for the victim network. Often times, the actors are able to harvest administrative user credentials and use the credentials to move laterally through a network.
    [Show full text]
  • Af-Saa-Api-Dlpi-0091.000
    Technical Committee Native ATM Services Data Link Provider Interface (DLPI) Addendum Version 1.0 AF-SAA-API-DLPI-0091.000 February, 1998 af-saa-api-dlpi-0091.000 Native ATM Services DLPI Addendum Version 1.0 © 1998 by The ATM Forum. The ATM Forum hereby grants its members the limited right to reproduce in whole, but not in part, this specification for its members internal use only and not for further distribution. This right shall not be, and is not, transferable. All other rights reserved. Except as expressly stated in this notice, no part of this document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum. The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. The receipt or any use of this document or its contents does not in any way create by implication or otherwise: • Any
    [Show full text]