Subject: [Tsvwg] 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

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

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

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 8 Feb 2002 12:46:56 +0100

Hi, Tim, and others,

please see the comments below...

On Wednesday, 6. February 2002 15:30, Tim Chown wrote:
> > 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.
>
> multihoming issues?   

No, in general it refers to one or more network layer addresses.
It tries to address issues that may come up with redundancy, where 
there are asymmetric path combinations (e.g. there is only one interface 
on one side, the (direct) link of which fails -- i.e. if you have 
several addresses configured on that interface, all these will fail 
for SCTP, if the link fails etc.).

> In IPv6, as you point out, each interface can have

Yes, I agree that this is not something new for IPv6, but that comment
was meant also for IPv4, where that is not generally true. So the section
should stay there, but maybe something can be added to clarify this.
What would be your suggestion ?

> In general, more consideration could be given for IPv6, perhaps?  

Maybe you could be a bit more descriptive. While we sure have great
consideration for IPv6, what do you feel is missing ?

Thank you for the comments, anyway,

regards,

Andreas

- -- 
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 8 Feb 2002 13:13:51 +0100

Hi Pekka, hello all,

please see my comments below:

> ==> what are "host routing tables" ?

I suppose that is what you get when you type in "netstat -rn" on a decent
unix machine. Anyway, this is probably confusing: it should probably say
something like "...and how the SCTP multihoming interacts with routing"
since that is what is of concern here: the interface between a transport
protocol and the network layer.

> and if it fails, just (try to) switch to the next one, right?

Any host that has an IP address has some routing tables. Richard Stevens 
has put that nicely in his "TCP/IP Illustrated, Vol.1 - The Protocols", 
chapter 9. That's recommended reading :-)

> to be able to do ALG translation), right?  Can be deleted.

What exactly can be deleted ?
Well, actually that section probably has not taken consideration at 
all of single-homed NATs (which in turn is not something that comes to 
mind at once when talking about a NAT). 
This is needed because single-homed _SCTP_ works together with NATs nicely 
(because no multiple IP addresses are carried inside the SCTP packets in the 
association setup phase), but multi-homed SCTP carries these IP addresses 
inside the INIT and INIT ACK chunks, so something needs to be tweaked in
that case.

> ==> note: all SCTP+IPSEC implementations would have to do this to be

Yep. Where I am not sure as to which IPSec implementations support this
(if any). This note should be added, just to be sure no one gets confused.

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

And I agree there, too. That is a true "non-sentence" :-)

> and capturing traffic: granted, this is an SCTP concern but is highlighted

No it is not, because SCTP according to all RFC 2960 does not
allow for adding addresses. 

Best regards, and thanks for the comments,

Andreas
- --

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 16:46:40 +0200 (EET)

> protocol and the network layer.

That seems more sane, or 'routing tables on hosts'.

> chapter 9. That's recommended reading :-)

I know my Stevens very well, thank you.

If you read the draft around that place, you'll notice the question was 
about SCTP hosts somehow having to dump routing tables _from a router_ on 
hosts to make sensible decisions.  My belief is that "regular" routing 
table (ie. basically about 4 routes) is enough.

> What exactly can be deleted ?

Whole section 2.3.  Or perhaps, some considerations might be  preservable.

> inside the INIT and INIT ACK chunks, so something needs to be tweaked in

If you use IP+SCTP, NAT still has to support rewriting the port numbers 
and IP numbers.  Therefore I gather NAT will have to be modified anyway 
cope with the fact.  This will probably include going into INIT/INIT ACK 
chunks, no?  

Anyway, multihoming through _one_ NAT seems rather stupid.  Via different 
NAT boxes it might even make a little sense.

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 8 Feb 2002 17:30:44 +0100

Pekka, dear all,

please see my comments inline...

> I know my Stevens very well, thank you.

Sorry, I couldn't resist :)

> table (ie. basically about 4 routes) is enough.

We agree on that point. If I want to use SCTP multi-homing sensibly, I must
rely on the fact that my network is administered in a way that *sensibly*
supports this, and that my network admin gives me the right data to install
the right routing tables on my host. 
Any installation of routes from a router basically would make the end-system
participate in a dynamic routing protocol. That is not necessarily needed, 
but, on the other hand, is nothing special, either.

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

No, it might need to be rewritten, but there must be a statement
about SCTP/NAT interaction ! We (and many others) want to know about
it...
 
> cope with the fact.  This will probably include going into INIT/INIT ACK

Yes, you are right: 
A NAT box will do the exact same thing for SCTP as it does for TCP
iff the concerned SCTP association is single-homed.
Only if an SCTP association is multi-homed, the NAT needs to also
dig into the INIT/INIT-ACK fields to modifiy these.
Since a NAT box cannot know a priori whether an association is
single- or multi-homed, it will in any case have to search through
the entire INIT/INIT-ACK chunks to check for addresses.

> Anyway, multihoming through _one_ NAT seems rather stupid.  
Talking from the redundancy viewpoint that sure is correct. 
"NATs are nasty. Don't use them for SCTP." 
Maybe that suffices in the draft ???

> Via different NAT boxes it might even make a little sense.
...and you got yourself a whole lot of other problems...

Well: one NAT box is a single point of failure, many NAT boxes
would build up many,many states -- that seems to be an interesting
problem so far unsolved, isn't it ?

- --

---

From: Arun Prasad <[email-masked]>
Date: Mon, 11 Feb 2002 11:20:17 +0530

hi Coene,
    Regarding the below section in the draft,
    2.2 SCTP multihoming and the size of routing tables
    what are we trying to achieve....   section 2.1 basically explained the restrictions
of SCTP's multihoming feature due to existing IP architecture....  The problems
are well sorted out, and one solution I get from that is,   changing the Source
Ip address for the packets send ( periodically, if the acknowledgemnet for it is
not reaching the endpoint,) from a multihomed endpoint....
    But regarding section 2.2,  SCTP could do nothing about it ( because its
basically IP's restriction or the restriction of the currect routing architecture....)
SCTP defines some rules or features, using them properly is the responsiblity of the
Application which uses it (it may the administrator of the system also...) ..  This
each of them using it can implement their own ways to get the maximum from use
of multihoming feature of SCTP......
      Will it not make SCTP more heavy, if we try to load it with more and more
sub features like this... and it will make it more dependent on the existing architecture
which will make the maintanance tough.....
    But definitely we should be spelling out the problems or restrictions of the
multihoming feature of SCTP, with which the users of SCTP users will do
appropriate action to use it best....

Is the observation valid??

Thanks
-arun

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************

---

From: Randall Stewart <[email-masked]>
Date: Mon, 11 Feb 2002 07:53:42 -0600

Arun:

I don't think we need to have a host become
routing aware as section 2.2 seems to imply to
some degree. Some clever work with the routing
system in the host can alleviate the problem that
Lode is mentioning here I think..

For example in our BSD work we have now the ability
of the routing system to have multiple default routes
and a method to lookup a route via an alternate interface.
We probably need to expand this to actually look at the gateway
and not the interface.. but for now we use interface :/

This allows the sctp stack to call 

rtalloc_alternate(dst,old_route);

which then trys to give a route out a different interface if
necessary hunting up the routing tree.

With this change we then get:

A) The host only needs to know about the edge routes available
   via its multiple default routes.

B) Full use of the multi-homing provided without injection
   of static routes as the v4 side does now...

C) Host only knows about the default routes and possibly
   some special routes applied by the local administrator...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Mon, 11 Feb 2002 08:00:33 -0600

Andreas Jungmaier wrote:
...snip...snip...
> allow for adding addresses.

Andreas:

The current RFC does not allow the addition of addresses but
the extension in the tsvwg does.. aka sctp-addip...

R

---

From: Andreas Jungmaier <[email-masked]>
Date: Mon, 11 Feb 2002 18:21:05 +0100

Hi Randy, 

I count on testing the extension on the Connectathon, so I was 
actually aware of that :-) 
However, the security section should only address the SCTP base 
protocol, I think, so there is no need to add that. It should 
be mentioned (and I think it already is)  in the security section 
of the add-ip draft.

Best regards,
Andreas

On Monday, 11. February 2002 15:00, Randall Stewart wrote:
> Andreas Jungmaier wrote:
> ...snip...snip...
>
> > > ==> consider the security of introducing new addresses to the
> > > association and capturing traffic: granted, this is an SCTP concern but
> > > is highlighted
> >

- --

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 11 Feb 2002 22:01:11 -0600

Randall,

Gee, I think the SCTP only needs to know the IP address.
IP does the rest.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Andreas Jungmaier <[email-masked]>
Date: Tue, 12 Feb 2002 12:15:03 +0100

Brian, 

I think with the modifications suggested by Randy one would
obtain better performance/better failover behaviour in a typical 
network failure scenario than were otherwise the case.
(otherwise == with normal routing, one default route)

Best regards,
Andreas

- --

---

From: Randall Stewart <[email-masked]>
Date: Tue, 12 Feb 2002 05:10:40 -0600

Andreas:

What is nice about the change I will be submitting
to KAME is it provides for ANY transport to be able
to take better account of them being multi-homed.

It is not strictly a transport type change.. but a modification
to the routing system. I think the base problem is that when
BSD was built multi-homing was not considered an important
issue...

R

Andreas Jungmaier wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE8aPk3XAsLBNOCSsARAileAKC6uaW7C3CzMTEktuFrtYatzSh61ACeL52k
> fwb1bJG49MBAZCwj5vSU6+A=
> =TNXt
> -----END PGP SIGNATURE-----
>