[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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