Comments on draft-nordmark-multi6-threats-01

Substantive comments:

> 1.1.  Assumptions
...
> 
>    This document doesn't assume that the application protocols are
>    protected by strong security today or in the future.  However, it is
>    still useful to assume that the application protocols which care
>    about integrity and/or confidentiality apply the relevant end-to-end
>    security measures, such as IPsec or TLS.

That's a narrow view of e2e security; I would add "and/or applications
level security."

> 2.  TERMINOLOGY
...
> 
>       interface   - a node's attachment to a link.

Is this intended to include virtual or pseudo interfaces
such as tunnel end points?

> 
>       address     - an IP layer name that contains both topological
>                     significance and acts as a unique identifier for an
>                     interface.

There may be multiple addresses per interface.

> 
>       locator     - an IP layer topological name for an interface or a
>                     set of interfaces.

There may be multiple locators per interface.

>       identifier  - an IP layer identifier for an IP layer endpoint
>                     (stack name in [NSRG]).  The transport endpoint is a
>                     function of the transport protocol and would
>                     typically include the IP identifier plus a port
>                     number.

Do we believe there may be multiple identifiers per interface or per host?

 > 3.1.  Application Assumptions
...
>    The second class of applications use existing IP source addresses
>    from outside of their immediate local site as a means of
>    authentication without any form of verification.  Today, with source
>    IP address spoofing and TCP sequence number guessing as rampant
>    attacks, such applications are effectively opening themselves for
>    public connectivity and are reliant on other systems, such as
>    firewalls, for overall security.  We do not consider this class of
>    systems in this document.

...because they are in any case fully open to all forms of network
layer spoofing.

>    The third class of applications receive existing IP source addresses,
>    but attempt some verification using the DNS, effectively using the
>    FQDN for access control. (This is typically done by performing a
>    reverse lookup from the IP address followed by a forward lookup and
>    verifying that the IP address matches one of the addresses returned
>    from the forward lookup.)  These applications are already subject to
>    a number of attacks using techniques like source address spoofing and
>    TCP sequence number guessing since an attacker, knowing this is the
>    case, can simply create a DoS attack using a forged source address
>    that has authentic DNS records.  In general this class of
>    applications is strongly discouraged, but it is probably important
>    that a multihoming solution doesn't introduce any new and easier ways
>    to perform such attacks.

But do we desire to make reverse lookup checks for multihomed sites
succeed, to avoid multihoming failures for hosts using the broken
technique?

>    Finally, the fifth class of applications use cryptographic security
>    techniques but without strong identity (such as opportunistic IPsec).
>    Thus data integrity with or without confidentiality is provided when
>    communicating with an unknown/unauthenticated principal.  Just like
>    the first category above such applications can't perform access
>    control since they do not know the identity of the peer. 

This is true *at network level* but they may well have applications
level strong identity and that may be necessary and sufficient.

Nits:

 > 2.  TERMINOLOGY
...
 >     FQDN        - Fully Qualified Domain Name

I would add a reference to RFC 1594, which seems to be the only place
that FQDN is defined

> 3.1.  Application Assumptions
> 
>    In the Internet today, the initiating part of applications either
>    starts with a FQDN, which it looks up in the DNS, or already has an
>    IP address from somewhere.  For the FQDN to IP address lookup the
>    application effectively places trust in the DNS.  Once it has the IP
>    address, the application places trust in the routing system
>    delivering packets to that address.  Applications that use security
>    mechanisms, such as IPsec or TLS, with mutual authentication have the
>    ability to "bind" the FQDN to the cryptographic keying material thus
--------------------------------------------------------------------^^
missing punctuation
>    compromising the DNS and/or the routing system can at worst cause the
>    packets to be dropped or delivered to an entity which does not posses
>    the keying material.

...
> 5.  GRANULARITY OF REDIRECTION
> 
>    Different multihoming solutions might approach the problem at
>    different layers in the protocol stack.  For instance, there has been
------------------------------------------------------------------^^^
grammar
>    proposals on a shim layer inside IP as well as transport layer
---------------^^
grammar
>    approaches.  

     Brian