Subject: SCTP multihoming issues draft

From: Coene Lode <[email-masked]>
Date: Wed, 6 Feb 2002 12:53:46 +0100

Previous week, the draft on SCTP multihoming issues was published.

Apart from some editorial changes concerning author list and missing/wrong
page numbers,
the only major change is a sentence added at the end of paragraph 2.3 SCTP
multihoming and Network Adress Translators(NAT):
"It should be noted that the NAT box becomes a single
    point-of-failure in this case, as ALL the paths of the SCTP
    association have to go through that single NAT box."
Theoretical it is possible to let all the different paths run through
different NAT boxes, but then the NAT boxes would never know exactly when to
teardown/terminate the association as the terminate or abort takes only one
of the paths(and there are other difficulties, such as the heartbeats
...etc...) So in practical terms this sentence should be correct. If you
feel otherwise, please let me know and I'll remove or add something to it to
make everything clear.

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.

yours sincerly
Lode Coene

---

From: Tim Chown <[email-masked]>
Date: Wed, 6 Feb 2002 14:30:38 +0000 (GMT)

> would ask for this draft to be moved to informational.

Does the draft have to only consider two network interfaces for the
multihoming issues?   In IPv6, as you point out, each interface can have
more than one IPv6 address (and addresses of many scopes), so the simplest
multihoming case for IPv6 is a host (endpoint) with one interface, 
recieving two different /64 prefix RAs, and thus having two IPv6 addresses
from two different providers.   The dual interface scenario may be useful 
of course, e.g. when considering wired and air interfaces.

When you say "it is recommended that IP addresses in a multihomed endpoint 
be assigned IP endpoints from different TLA's to ensure against network 
failure", this would be the default case for IPv6.  

For IPv6, delete section 2.3 :-)

In general, more consideration could be given for IPv6, perhaps?  (you 
did cc multi6 :-)   If I've misinterpreted the text, perhaps the title
of the draft needs revision?

Best wishes,
Tim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 12:22:47 +0200 (EET)

> 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