Re: SCTP multihoming issues draft

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 6 Feb 2002, Coene Lode wrote:
> Previous week, the draft on SCTP multihoming issues was published.
> 
> The draft can be found at the IETF draft directory: 
> Multihoming issues in the Stream Control Transmission Protocol
> <draft-coene-sctp-multihome-02.txt>
> 
> If by then end of next week, no further issues have been identified, then I
> would ask for this draft to be moved to informational.

This is not a multi6 issue as such, as SCTP does not really provide site 
multihoming (however, SCTP may enable site multihoming with multiple 
addresses per node, so this may be in the scope of wg even though it most 
probably doesn't meet the requirements in the requirements document).

But anyway, I read the draft on a flight.  A few comments:

(first a few editorial nits)

Abstract

    This document describes issues of the Stream Control Transmission
    Protocol (SCTP)[RFC2960] in regard to multihoming on the
    Internet. It explores cases where through situations in the
    internet, single points-of-failure can occur even when using
    multihoming and what the impact is of multihoming on the host
    routing tables.

==> what are "host routing tables" ?

1 Introduction


    SCTP[RFC2960] is a transport protocol that uses multihoming. This   
    draft is a attempt at identifying the issues that may arise in the  
    layers below SCTP when multihoming is used by SCTP. Some issues are
    already being addresses in various other WG and this document will
    try to highlight them. If the solutions would resolve the issues
    presented in this document then the problem presented is no longer
    an issue. This document will also try to gauge the effectiveness of
    the present multihoming architecture.

==> s/a attempt/an attempt/, s/WG/WGs/

2.1 Interaction with routing

    Under the assumption that every IP address will have a different,
    seperate paths towards the remote endpoint, (this is the
    responsibility of the routing protocols or of manual configuration)

==> s/paths/path/, s/endpoint,/endpoint/

    It might be usefull to explore ways where no routing tables are

==> s/usefull/useful/

==> on a generic note: it seems to me there is a need for routing tables 
on hosts only if one wants to optimize the paths: one is used by default, 
and if it fails, just (try to) switch to the next one, right?

2.3 SCTP multihoming and Network Adress Translators(NAT)

==> this very same problem will come up with single-homed NAT's too (need
to be able to do ALG translation), right?  Can be deleted.

2.4 SCTP multihoming and IPsec

 A much better
    implementation approach is to simply use groups of addresses instead
    of single ones.

==> note: all SCTP+IPSEC implementations would have to do this to be
compatible, it appears.

3 Security considerations

    As such the use of multihoming does not provide security risks. The
    solutions needed for allowing multihoming may provide security
    risks.

==> this seems like a circular argument: SCTP is such a solution.

==> consider the security of introducing new addresses to the association 
and capturing traffic: granted, this is an SCTP concern but is highlighted 
by multihoming.  This cannot be handwaved by IPSEC unless IPSEC is 
required for all SCTP.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords