RE: SCTP multihoming issues draft

[Coene Lode <Lode.Coene@siemens.atea.be>]

I'll reply to all mailing lists (..crosssposting be dammed...)

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: vrijdag 8 februari 2002 11:23
> To: Coene Lode
> Cc: Transport Area wg (E-mail); SIGTRAN (E-mail); 
> 'multi6@ops.ietf.org'
> Subject: Re: SCTP multihoming issues draft
> 
> 
> 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).

Not sure that we are part of the solution space. Am waiting for a release of
the requirements document to see if any of the requirements make live hard
for SCTP multihoming.

> 
> 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" ?
selecting the correct outgoing link is a routing descision. See also Andreas
comments (with which I agree).
> 
> 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/

Fixed

> 
> 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/

fixed

> 
>     It might be usefull to explore ways where no routing tables are
> 
> ==> s/usefull/useful/

fixed
> 
> ==> 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?
> 

See previous remark on routing tables.

> 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.

The single home case is rather straight forward(and works nicely together
with NAT's as Andreas points out), but it is a multihomed SCTP association
which will make live (very) difficult for NAT boxes, esspecially if the NAT
box doesn't want to be the single point of failure. So this paragraph is
rigth to the point.

What this paragraph says(between the lines) is: do not use NAT boxes if you
ever want true multihoming.

> 
> 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.

We'll add a note(above is a good line).

> 
> 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.

I'll remove the first sentence. Then it isn't a circular argument.
The second sentence would then say that SCTP migth provide security risks
when using multihoming(but we don't know them yet)

> 
> ==> 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.

adding(or removing) addresses to a association is not part of the baseline
SCTP spec. That is a addition in the works (see
http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-04.txt
This document only talks about the present SCTP capabilities.

> 
> -- 
> 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
>

Thanks for the remarks. They have been helpfull.

yours sincerly,
Lode Coene