Information-Centric Networks Section # 6.3: Evolved Naming & Resolution Instructor: George Xylomenos...

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Information-Centric Networks Section # 6.3: Evolved Naming & Resolution Instructor: George Xylomenos...

Information-Centric NetworksSection # 6.3: Evolved Naming & ResolutionInstructor: George XylomenosDepartment: Informatics

1FundingThese educational materials have been developed as part of the instructors educational tasks.The Athens University of Economics and Business Open Courses project only funded the reformatting of these educational materials. The project is being implemented as part of the Operational Program Instruction and Lifelong Learning and is co-financed by the European Union (European Social Fund) and national funds.

2LicencingThese educational materials are subject to a Creative Commons License.

3Information-Centric Networks06c-4Week 6 / Paper 3Middleboxes No Longer Considered HarmfulMichael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris, Scott ShenkerOperating Systems Design & Implementation (OSDI), 2004Main pointMiddleboxes are everywhereInternet purists scorn middleboxes (with reason)But middleboxes offer valuable functionalityHow can we retain the functionality without the side-effects?The answer: Delegation Oriented Architecture (DOA)Subset of the layered naming architecture4IntroductionTwo Internet tenets are often disobeyedEvery Internet entity has a unique network level identifierNAT and host mobility prevent thisNetwork elements should not process others packetsCaches, firewalls, NATs regularly look inside passing packetsLayer violations make lead to real problemsSIP and P2P systems are hindered by IP address translationHard to deploy new applicationsBut middleboxes offer useful functionsIt would be even better if they could be located off-pathThe Delegation Oriented Architecture (DOA)Globally unique identifiers in a flat namespaceSenders and receivers can indicate multiple such identifiersInformation-Centric Networks06c-5NATs, NAPTs and FirewallsNAT and NAPTHide networks with private addresses behind a public addressNAPT looks at address and port, NAT only at addressNAT nearly always means NAT, so we only use this termConvenience and flexibility in internal addressingSecurity since only outbound connections are allowedStatic configuration needed to handle inbound connectionsNo way to use the same port for two applicationsFirewallsInspect inbound and outbound packetsEnforce filtering rulesNeed to be on the path to the endpointInformation-Centric Networks06c-6Architectural overviewDesired architectural propertiesPackets should contain global identifiersAs used to be the case with IPApplication-independent way to express delegationDelegates should not have to be on the direct pathEIDs: endpoint identifiersMust be independent of network topologyCan carry cryptographic meaning160 bit flat EIDs were chosenCarried in a header between TCP and IPEIDs can be resolved to two thingsAn IP address (could be the delegates)One or more EIDs, as in a loose source routeInformation-Centric Networks06c-7Architectural overviewDOA and the two Internet tenetsEIDs are globally unique identifiersPackets sent to EIDs actually reach the hosts with these EIDsNetwork elements only process packets with their own IPA delegate can see that the EID does not match its ownIt then resorts to local state to further forward the packetNo need for complex configuration at NATsJust send the packet to the host with the right EIDDOA and Internet evolvabilityDOA allows managed service provisionYou select your firewall provider and delegate packets to itInformation-Centric Networks06c-8Detailed DOA designHeader formatDOA header inserted between TCP and IP headersTCP uses EIDs for checksum calculationsCarries at least one source and one destination EIDCan be extendedResolution and invoking intermediariesThe EID is resolved to an erecord containing:EID being resolvedTarget: IP or one or more EIDsHint (optional)TTL: caching timeTransport connections are bound to the last EIDThe others need to be traversed on the way to the destinationInformation-Centric Networks06c-9Detailed DOA designSecurity and IntegrityAnyone fetching an erecord must be able to verify its EIDOnly the owner of an EID should update its erecordA sender must not be able to forge an erecordEIDs are the hash of a public keyThe erecord is signed with the corresponding private keyDoes not prevent source EID spoofingThe receiver resolves the EID again to return responsesHost softwareModified socket calls using a sockaddr_ein structConnect() and sendto() may require EID lookupsAccept() will return an EIDHosts need to be bootstrapped with an EID resolverInformation-Centric Networks06c-10Network extension boxesNetwork Extension Box (NEB): akin to a NATOffers some kind of delegated functionalityPreserve headers, using the EID to demultiplex packetsSimply insert the right IP address for the EID in the packetEnd-to-end communication possiblePorts are not overloadedVPNs can work around NEBsNEBs can be configured automaticallyConfiguration of cascaded NEBsThe endpoint must know what to put in its erecordState must be established at NEBs or in the resolversThis state must not be modified by attackersAssume that each NEB only trusts the upstream NEBInformation-Centric Networks06c-11Network extension boxesEID maps to EIDEach NEB adds an erecord from its EID to its parents EIDEach NEB holds a mapping from its childrens EIDs to their IPsIncoming packets are resolved to a sequence of EIDsAs they pass NEBs they are sent to the next IP addressEID maps to EID and a hintAs above, but the erecord also holds the IP address in the HintThe IP addresses are included in the headerEach NEB can find the next IP address without internal stateEID maps to IP addressThree round protocol to establish state at all NEBsMore complex, but the one actually implementedOnly requires a single EID to IP lookup by the senderInformation-Centric Networks06c-12Network filtering boxesNetwork Filtering Box (NFB): akin to a firewallEssentially remote packet filtersNo need to be on the path to the endpointThe NFB can work in statefull or stateless mode (as with NEBs)The NFB receives packets and checks its rule basePackets that pass the rules are attestedThe NFB hashes the passed packet and signs the hashA secret key shared between NFB and endpoint is usedCarried in an extension headerThe endpoint only accepts packets attested by the NFBOf course NEB and NFB can be combined in a chainCan also be combined with an on-path middleboxThat middlebox can then check that packets are attestedInformation-Centric Networks06c-13ImplementationUser level software and Click modules in LinuxClick is a modular router building toolkitRuns at both user and kernel levelsAllows mature implementations to migrate to the kernelUser level daemon (doad) resolves EIDs to erecordsQueries the DHT infrastructureInserts the EID to IP mapping in Click with a private IPReturns the private IP to the client applicationThe client sends the packet with the private IPClick rewrites the packet with the real IP and EIDNEB prototype: user level implementationNFB pototype: user level and Click modulesClick module for clients to verify attested packetsInformation-Centric Networks06c-14EvaluationRound-trip timesA DNS and a DHT lookup are needed for resolutionDNS lookups take from 70 to 190 ms depending on cachingMedian DHT lookups require 138 ms: needs improvementProactive caching as in BeehiveDNS names could also return erecordsHosts could include their erecords in messagesPacket size overhead68 byte header (44 fixed and 24 for security extension)For large packets small overhead, for small packets quite highProcessing timeDOA to IP translation does not take a lotFiltering and verification take far more timeInformation-Centric Networks06c-15End of Section # 6.3Course: Information-Centric Networks, Section # 6.3: Evolved Naming & ResolutionInstructor: George Xylomenos, Department: Informatics