Subject: [Tsvwg] Re: Multihoming with NAT

From: Qiaobing Xie <[email-masked]>
Date: Wed, 04 Dec 2002 14:38:20 -0600

Hi, La Monte,

(cc'ing this to tvswg list... this is more than implementation I think)

...
> I'm not convinced that we have an immediate and burning need for work
> on multi-homed SCTP support behind multiple NAT boxen.  I'll not go so
> far as to say that work on "Inter-NAT SCTP Coordination Protocol"
> would be a BAD idea.  I just think that the SCTP community has more
> important work right now.

I don't think I can speak for the SCTP users, though :-) For those companies who
are currently looking at deploying SCTP for their services (I hope there are) and
their infrastructure already contains multiple NAT/middle boxes, this becomes an
"immediate and burning" need.

Personally, I feel the same as you do, that I don't have any bandwidth to work on
the problem now. But I wouldn't discourage others from work on it. There are
plentiful of works going on, across multiple WGs, to address UDP and TCP middle
box transverse issues, such as stun, but very little is happening for SCTP, which
is not good for SCTP's future. I wish someone could have cycles to follow those
works and ensure SCTP is adequately considered in their solutions.

Technically, SCTP's multi-homing nature does make it more a challenge than UDP and
TCP for middle box transverse, but I don't think it is un-solvable. The hostname
parameter in SCTP just gives SCTP one more weapon/tool/flexibility than TCP or UDP
to deal with the problem. And in my mind I don't automatically map the SCTP
hostname parameter to a DNS-qualified hostname - since it is defined as a TLV, I'd
prefer to view the parameter as a versatile, generic alternative addressing id.
It's a hook, not a solution by itself, that could be mapped to things such as a
DNS hostname, some host ID, enum number, pool handle, some user-defined ID... or
whatever deemed necessary and useful by a specific solution.

I'd love to see someone starting work on this, with or without using the hostname
param, and I will try to help anyway I can. This is basically the intention of my
first comments.

-Qiaobing

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 17:45:52 -0700

Qiaobing,

Unfortunately the Host Name parameter has already been defined to
have strict RFC1123 Section 2.1 "host name syntax."  This is not
a URL (which would have even worse security implications than host
name already has).

IMO any approach which doesn't relay upon strict coordination between
multiple-NATs will open up multi-homed SCTP associations to all manner
of attacks.

--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 ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 04 Dec 2002 20:59:17 -0600

Hi, Brian,

"Brian F. G. Bidulock" wrote:
......
> a URL (which would have even worse security implications than host

I don't think we should hang ourselves under that definition if in the future
someone comes up with a legitimate use of that TLV but requires a different "name"
syntax. Also, a solution may be found without relying on that TLV at all.

> multiple-NATs will open up multi-homed SCTP associations to all manner

Agreed. Any solution must address security issues, just as we are reminded
constantly by IESG  :-)

-Qiaobing