Re: [RTG-DIR] RtgDir review: draft-ietf-hip-rfc4423-bis-19

[Miika Komu <[e-mail]>]

Hi Dan,

some of the missing comments are mentioned below. Sorry for the delay 
but it took some while to write completely new text into the draft.

On 04/06/2018 10:43 AM, Miika Komu wrote:
> Hi Dan,
> 
> thanks for the feedback and sorry for the long delay! Some comments below.
> 
> On 03/05/2018 05:18 PM, Dan Frost wrote:
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this 
>> draft. The Routing Directorate seeks to review all routing or 
>> routing-related drafts as they pass through IETF last call and IESG 
>> review, and sometimes on special request. The purpose of the review is 
>> to provide assistance to the Routing ADs. For more information about 
>> the Routing Directorate, please see ​ 
>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>> Although these comments are primarily for the use of the Routing ADs, 
>> it would be helpful if you could consider them along with any other 
>> IETF Last Call comments that you receive, and strive to resolve them 
>> through discussion or by updating the draft.
>>
>> Document: draft-ietf-hip-rfc4423-bis-19
>> Reviewer: Dan Frost
>> Review Date: 2017-03-05
>> Intended Status: Informational
>>
>> Summary:
>>
>> I have some minor concerns about this document that I think should be 
>> resolved before publication.
>>
>> Comments:
>>
>> This document describes an overall architecture for a proposed "Host 
>> Identity" layer that fits in to the Internet protocol stack between 
>> the network and transport layers. The architecture involves adding a 
>> layer of indirection between the IP and transport layers that 
>> allocates globally-significant host identifiers in the form of 
>> cryptographic public keys, and manages network-layer-independent 
>> associations between hosts. This draft is a revision of RFC 4423, 
>> which was originally published in 2006, so the basic architecture has 
>> been around for some time, and seen some limited deployment experience.
>>
>> The document itself is clearly written, and thorough in addressing the 
>> many issues and concerns raised by such a proposal without being verbose.
>>
>> There's a lot of valuable protocol design and deployment experience 
>> packed into this architecture and the associated protocol RFCs. At the 
>> same time, actual adoption and deployment of HIP so far appears to 
>> have been scarce. I don't find this surprising. The existing Internet 
>> network/transport/application protocol stack has already become 
>> sufficiently complicated that considerable expertise is required to 
>> manage it in all but the simplest of cases. Teams of skilled engineers 
>> routinely spend hours or days troubleshooting operational problems 
>> that crop up within or between the existing layers, and the collection 
>> of extensions, workarounds, identifiers, knobs, and failure cases 
>> continues to grow. Adding a major new layer--and a fairly complicated 
>> one at that--right in the middle of the existing stack seems likely to 
>> explode the already heavily-strained operational complexity budget of 
>> production deployments.

while this wasn't an issue, I asked some input on this from Tempered 
Networks (that has a number of HIP products) and we wrote together some 
text to address at least some of your concerns.

11.2.  Drawbacks of HIP (Added a sentence in the end of the paragraph)

O HIP introduces a need to manage the new identities and requires a
centralized approach to manage HIP-aware endpoints at scale. [...] As 
exemplified in Section 11.3.5, these challenges have been already solved 
in an infrastructure setting to distribute policy and manage the 
mappings and trust relationships between HIP-aware endpoints.

11.3.5.  Management of Identities in a Commercial Product (New section)

    Tempered Networks provides HIP-based products.  They refer to their
    platform as Identity-Defined Networking (IDN) [tempered-networks]
    because of HIP's identity-first networking architecture.  Their
    objective has been to make it simple and non-disruptive to deploy HIP
    enabled services widely in production environments with the purpose
    of enabling transparent device authentication and authorization,
    cloaking, segmentation, and end-to-end networking.  The goal is to
    eliminate much of the circular dependencies, exploits, and layered
    complexity of traditional "address-defined networking" that prevents
    mobility and verifiable device access control.  The products in the
    portfolio of Tempered Networks utilize HIP as follows:

    o  HIP Switches / Gateways - these are physical or virtual appliances
       that serve as the HIP gateway and policy enforcement point for non
       HIP-aware applications and devices located behind it.  No IP or
       infrastructure changes are required in order to connect, cloak,
       and protect the non-HIP aware devices.  Currently known supported
       platforms for HIP gateways are: x86 and ARM chipsets, ESXi, Hyper-
       V, KVM, AWS, Azure, and Google clouds.

    o  HIP Relays / Rendezvous - are physical or virtual appliances that
       serve as identity based routers authorizing and bridging HIP
       endpoints without decrypting the HIP session.  A HIP Relay can be
       deployed as a standalone appliance or in a cluster for horizontal
       scaling.  All HIP aware endpoints and the devices they're
       connecting and protecting can remain privately addressed, The
       appliances eliminate IP conflicts, tunnel through NAT and CGNAT,
       and require no changes to the underlay infrastructure.  The only
       requirement is that a HIP endpoint should have outbound access to
       the Internet and that a HIP Relay should have a public address.

    o  HIP-Aware Clients and Servers - software that installs in the
       host's network stack and enforces policy for that host.  HIP
       clients support split tunneling.  Both HIP client and HIP server
       can interface with the local host firewall and HIP Server can be
       locked down to listen only on the port used for HIP, making the
       server invisible from unauthorized devices.  Currently known
       supported platforms are Windows, OSX, iOS, Android, Ubuntu, CentOS
       and other Linux derivatives.

    o  Policy Orchestration Managers - a physical or virtual appliance
       that serves as the engine to define and distribute network and
       security policy (HI and IP mappings, overlay networks and
       whitelist policies etc.) to HIP-aware endpoints.  Orchestration
       does not need to persist to the HIP endpoints and vice versa
       allowing for autonomous host networking and security.

>> Major Issues:
>>
>> No major issues found.
>>
>> Minor Issues:
>>
>> - Section 1
>>
>> It would be good to clarify early in this section that the Host 
>> Identity namespace is global.
> 
> Fixed:
> 
> The proposed Host Identity namespace is also a global namespace, and it 
> fills an important gap between the IP and DNS namespaces.
> 
>> - Section 1, paragraph 4, last sentence
>>
>> Some grammar problems here.
> 
> Fixed.
> 
>> - Section 3, last paragraph
>>
>> This paragraph says "Firstly, dynamic readdressing cannot be directly 
>> managed." It's not entirely obvious what this refers to; some 
>> elaboration or a reference would be helpful.
> 
> I would suggest to change this as follows:
> 
> Firstly, establishing initial contact and sustaining of data
> flows between two hosts can be challenging due to private address
> realms and ephemeral nature of addresses.
> 
> Is it more clear now and do you need a reference? I am referring to the 
> issues that vanilla TCP/IP cannot sustain session connectivity upon 
> address changes and connecting to hosts behind NATs is not possible 
> without external help (such as ICE, Teredo).
> 
>> - Sections 5 and 10
>>
>> These sections contain some discussion of opportunistic mode. The 
>> draft would benefit from some expanded coverage of this subject, such 
>> as whether and how a TOFU approach is expected to apply, and a 
>> comparison against the considerations raised in RFC 7435.
> 
> I have added a new section dedicated to this.

The text is here:

12.5.  Trust On First Use

    [RFC7435] highlights four design principles for Leap of Faith, or
    Trust On First Use (TOFU), protocols that apply also to opportunistic
    HIP:

    1.  Coexist with explicit policy

    2.  Prioritize communication

    3.  Maximize security peer by peer

    4.  No misrepresentation of security

    According to the first TOFU design principle, "opportunistic security
    never displaces or preempts explicit policy".  Some application data
    may be too sensitive, so the related policy could require
    authentication (i.e, the public key or certificate) in such a case
    instead of the unauthenticated opportunistic mode.  In practice, this
    has been realized in HIP implementations as follows [RFC6538].

    The OpenHIP implementation allowed an Initiator to use opportunistic
    mode only with an explicitly configured Responder IP address, when
    the Responder's HIT is unknown.  At the Responder, OpenHIP had an
    option to allow opportunistic mode with any Initiator -- trust any
    Initiator.

    HIP for Linux (HIPL) developers experimented with more fine-grained
    policies operating at the application level.  HIPL implementation
    utilized so called "LD_PRELOAD" hooking at the application layer that
    allowed a dynamically linked library to intercept socket-related
    calls without rebuilding the related application binaries.  The
    library acted as a shim layer between the application and transport
    layers.  The shim layer translated the non-HIP based socket calls
    from the application into HIP-based socket calls.  While the shim
    library involved some level of complexity as described in more detail
    in [komu-leap], it achieved the goal of applying opportunistic mode
    at the granularity of individual applications.

    The second TOFU principle essentially states that communication
    should be first class citizen instead of security.  So opportunistic
    mode should be, in general, allowed even if no authentication is
    present, and even possibly a fallback to non-encrypted communications
    could be allowed (if policy permits) instead of blocking
    communications.  In practice, this can be realized in three steps.
    In the first step, a HIP Initiator can look up the HI of a Responder
    from a directory such as DNS.  When the Initiator discovers a HI, it
    can use the HI for authentication and skip the rest of the following
    steps.  In the second step, the Initiator can, upon failing to find a
    HI, try opportunistic mode with the Responder.  In the third step,
    the Initiator can fall back to non-HIP based communications upon
    failing with opportunistic mode if the policy allows it.  This three
    step model has been implemented successfully and described in more
    detail in [komu-leap].

    The third TOFU principle suggests that security should be maximized,
    so that at least opportunistic security would be employed.  The three
    step model described earlier prefers authentication when it is
    available, e.g., via DNS records (and possibly even via DNSSEC when
    available) and falls back to opportunistic mode when no out-of-band
    credentials are available.  As the last resort, fallback to non-HIP
    based communications can be used if the policy allows it.  Also,
    since perfect forward security (PFS) is explicitly mentioned in the
    third design principle, it is worth mentioning that HIP supports it.

    The fourth TOFU principle states that users and non-interactive
    applications should be properly informed about the level of security
    being applied.  In practice, non-HIP aware applications would assume
    no extra security being applied, so misleading at least a non-
    interactive application should not be possible.  In the case of
    interactive desktop applications, system-level prompts have been
    utilized in earlier HIP experiments [karvonen-usable], [RFC6538] to
    guide the user about the underlying HIP-based security.  In general,
    users in those experiments perceived when HIP-based security was
    being used versus not used.  However, the users failed to notice the
    difference between opportunistic and non-opportunistic HIP.  The
    reason for this was that the opportunistic HIP (i.e. lowered level of
    security) was not clearly indicated in the prompt.  This provided a
    valuable lesson to further improve the user interface.

    In the case of HIP-aware applications, native sockets APIs for HIP as
    specified in [RFC6317] can be used to develop application-specific
    logic instead of using generic system-level prompting.  In such case,
    the application itself can directly prompt the user or otherwise
    manage the situation in other ways.  In this case, also non-
    interactive applications can properly log the level of security being
    employed because the developer can now explicitly program the use of
    authenticated HIP, opportunistic HIP and plain-text communication.

    It is worth mentioning a few additional items discussed in [RFC7435].
    Related to active attacks, HIP has built-in protection against
    cipher-suite down-grade attacks as described in detail in [RFC7401].
    In addition, pre-deployed certificates could be used to mitigate
    against active attacks in the case of opportunistic mode as mentioned
    in [RFC6538].

    Detection of peer capabilities is also mentioned in the TOFU context.
    As discussed in this section, the three-step model can be used to
    detect peer capabilities.  A host can achieve the first step of
    authentication, i.e., discovery of a public key, via DNS, for
    instance.  If the host found no keys, the host can then try
    opportunistic mode as the second step.  Upon a timeout, the host can
    then proceed to the third step by falling back to non-HIP based
    communications if the policy permits.  This last step is based on an
    implicit timeout rather an explicit (negative) acknowledgment like in
    the case of DNS, so the user may conclude prematurely that the
    connectivity has failed.  To speed up the detection phase by
    explicitly detecting if the peer supports opportunistic HIP,
    researchers have proposed TCP specific extensions [RFC6538],
    [komu-leap].  In a nutshell, an Initiator sends simultaneously both
    an opportunistic I1 packet and the related TCP SYN datagram equipped
    with a special TCP option to a peer.  If the peer supports HIP, it
    drops the SYN packet and responds with an R1.  If the peer is HIP
    incapable, it drops the HIP packet (and the unknown TCP option) and
    responds with a TCP SYN-ACK.  The benefit of the proposed scheme is
    faster, one round-trip fallback to non-HIP based communications.  The
    drawback is that the approach is tied to TCP (IP-options were also
    considered, but do not work well with firewalls and NATs).
    Naturally, the approach does not work against active attacker, but
    opportunistic mode is not anyway supposed to protect against such an
    adversary.

    It is worth noting that while the use of opportunistic mode has some
    benefits related to incremental deployment, it does not achieve all
    the benefits of authenticated HIP [komu-diss].  Namely, authenticated
    HIP supports persistent identifiers in the sense that hosts are
    identified with the same HI independently of their movement.
    Opportunistic HIP meets this goal only partially: after the first
    contact between two hosts, HIP can successfully sustain connectivity
    with its mobility management extensions, but problems emerge when the
    hosts close the HIP association and try to re-establish connectivity.
    As hosts can change their location, it is no longer guaranteed that
    the same IP address belongs to the same host.  The same address can
    be temporally assigned to different hosts, e.g., due to the reuse of
    IP addresses (e.g. by a DHCP service), overlapping private address
    realms (see also the discussion on Internet transparency in
    Section 11.1) or due to an attempted attack.


>> - Infrastructure devices
>>
>> The draft does not discuss the applicability of HIP to infrastructure 
>> devices. These devices are also hosts, and it's a little surprising 
>> that they're never mentioned as possible HIP users.
> 
> I have been writing a new section on this, including some input from 
> Tempered Networks on how their HIP product works. I need a bit more time 
> to complete this though.

The new section (note that Tempered Networks discussion is actually a 
separate section):

11.3.4.  Infrastructure Applications

    HIP experimentation report [RFC6538] enumerates a number of client
    and server applications that have been trialed with HIP.  Based on
    the report, this section highlights and complements some potential
    ways how HIP could be exploited in existing infrastructure such as
    routers, gateways and proxies.

    HIP has been successfully used with forward web proxies (i.e.,
    client-side proxies).  HIP was used between a client host (web
    browser) and a forward proxy (Apache server) that terminated the HIP/
    ESP-tunnel.  The forward web proxy translated HIP-based traffic
    originating from the client into non-HIP traffic towards any web
    server in the Internet.  Consequently, the HIP-capable client could
    communicate with HIP-incapable web servers.  This way, the client
    could utilize mobility support as provided by HIP while using the
    fixed IP address of the web proxy, for instance, to access services
    that were allowed only from the IP address range of the proxy.

    HIP has also been experimented with reverse web proxies (i.e. server-
    side proxies) as described in more detail in [komu-cloud].  In this
    scenario, a HIP-incapable client accessed a HIP-capable web service
    via an intermediary load balancer (that was a web based load balancer
    implementation called HAProxy).  The load balancer translated non-HIP
    traffic originating from the client into HIP-based traffic for the
    web service (consisting of front-end and back-end servers).  Both the
    load balancer and the web service were located in a datacenter.  One
    of the key benefits for encrypting the web traffic with HIP in this
    scenario was to support a private-public cloud scenario (i.e. hybrid
    cloud) where the load balancer, front-end servers and back-end
    servers can be located in different datacenters and, thus, the
    traffic needs to protected when it passes through potentially
    insecure networks between the borders of the private and public
    clouds.

    While HIP could be used to secure access to intermediary devices
    (e.g. access to switches with legacy telnet), it has also been used
    to secure intermittent connectivity between middlebox infrastructure.
    For instance, earlier research [komu-mitigation] utilized HIP between
    Secure Mail Transport Protocol (SMTP) servers in order to exploit the
    computational puzzles of HIP as a spam mitigation mechanism.  A
    rather obvious practical challenge in this approach was the lack of
    HIP adoption on existing SMTP servers.

    To avoid deployment hurdles with existing infrastructure, HIP could
    be applied in the context of new protocols with little deployment.
    Namely, HIP has been experimented in the context of a new protocol,
    peer-to-peer SIP [camarillo-p2psip].  The work has resulted in a
    number of related RFCs [RFC6078], [RFC6079], [RFC7086].  The key idea
    in the research work was to avoid redundant, time consuming ICE
    procedures by grouping different connections (i.e.  SIP and media
    streams) together using the low-layer HIP which executes NAT
    traversal procedures only once per host.  An interesting aspect in
    the approach was the use of P2P-SIP infrastructure as rendezvous
    servers for HIP control plane instead of utilizing the traditional
    HIP rendezvous services [RFC8004].

    Researchers have proposed to use HIP in cellular networks as a
    mobility, multihoming and security solution. [hip-lte] provides a
    security analysis and simulation measurements of using HIP in Long
    Term Evolution (LTE) backhaul networks.

    HIP has been experimented with securing cloud internal connectivity.
    First with virtual machines [komu-cloud] and then later also between
    Linux containers [ranjbar-synaptic].  In both cases, HIP was
    suggested as a solution NAT traversal that could be utilized both
    internally by a cloud network and between multi-cloud deployments.
    Specifically in the former case, HIP was beneficial sustaining
    connectivity with a virtual machine while it migrates to a new
    location.  In the latter case, Software-Defined Networking (SDN)
    controller acted as rendezvous server for HIP-capable containers.
    The controller enforced strong replay protection by adding middlebox
    nonces [heer-end-host] to the passing HIP base exchange and UPDATE
    messages.

>> - End user experience
>>
>> I didn't see a discussion of how the experience of an end user using a 
>> HIP-enabled application would differ as compared to the status quo. Is 
>> HIP expected to be completely transparent to end users? Do they need 
>> to understand the significance of public keys? What new kinds of 
>> errors might they have to deal with? Impact to end user usability 
>> seems like an important topic for the architecture to address.
> 
> The text on opportunistic HIP includes some insight on usability. If 
> needed, I can add a new section this if you need more information.

Did not add a new section, but the text on opportunistic mode includes 
some discussion on this topic.

> Dan, the new sections include quite a lot of text. Would you prefer to 
> receive them by email or should I post a new version of the draft?

A pre-version of the draft with the proposed changes is available here:

http://mkomu.kapsi.fi/temp/draft-ietf-hip-rfc4423-bis-20pre.txt

If needed, I can also post a new officia version for easier diffs?

Btw, Jeff Ahrenholz, Tom Henderson and Erik Giesa have been helping with 
the new text. Tom Henderson also suggested to change the following text 
in 11.3.1:

    HIP has commercially been utilized at Boeing airplane factory for
    their internal purposes [paine-hip].  It has been included in a
    security product called Tofino to support layer-two Virtual Private
    Networks [henderson-vpls] to facilitate, e.g, supervisory control and
    data acquisition (SCADA) security.

to:

    HIP has been adapted and deployed in an industrial control network
    in a production factory, in which HIP's strong network layer identity
    supports the secure coexistence of the control network with many
    untrusted network devices operated by third-party vendors [paine-hip].
    Similarly, HIP has also been included in a security product to 
support layer-two
    Virtual Private Networks [henderson-vpls] to enable security zones in a
    supervisory control and data acquisition (SCADA) network.

(To make it more vendor neutral)