Subject: RE: Multihoming with NAT

From: Serkan Cil <[email-masked]>
Date: Tue, 3 Dec 2002 08:53:26 -0500

Hi Randall,

please see my comments below.

Serkan

> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:[email-masked]]
> Sent: Monday, December 02, 2002 5:40 PM
> To: Serkan Cil
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Multihoming with NAT
> 
> 
> Serkan:
> 
> And so why would one what to do this? It seems to me that you
> are saying any IP packet headed for IP1' is translated and goes
> to IP1 (and of course the same for IP2')...
> 
> Why not just assign IP1' to the host?
> 

[Serkan] 
Say your host is in a corporate network and your NAT(s) is located on the
corporate
router(s) which connect to ISP(s). IMO the most suitable place for "the
host" would be 
behind the router rather than the front (i.e. outside). And there will be
cases where
you will have to do that just because of the IT policies etc. So in such
cases static
mapping would be needed.

> And even at that.. hostname addresses don't give you any
> advantage in this scenario..

[Serkan]
I am not clear why hostname address wouldn't be a solution. It seems to me
that
hostname address should work as long as it maps to IP1' and IP2'. 

> 
> R
> 
> Serkan Cil wrote:
> 
> >Hi,
> >
> >If we do not insist on IP multiplexing it is still possible 
> to support MH
> >behind a NAT.
> >NAT boxes can do static address mapping between the global
> >and local address spaces. This does not require any 
> information (port etc.)
> >from the protocol carried in IP packet. It is a simple 
> address mapping
> >operation.
> >Also NAT can work with a pool of global addresses and a pool of local
> >addresses.
> >So following scenario seems possible if we configure the 
> nat1 and nat2 to do
> >just the address mapping. We are basically reserving global 
> addresses IP1'
> >and IP2' for 
> >IP1 and IP2 mapping. "host" needs to send the INIT with 
> hostname param. 
> >(which is mapped to IP1' and IP2' in DNS or else)
> >
> >
> >     IP1           IP1'  
> > host -------nat1 ------ISP1
> >  |
> >  +----------nat2-------ISP2
> >     IP2           IP2'
> >
> >Serkan
> >
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: Randall Stewart (cisco) [mailto:[email-masked]]
> >>Sent: Thursday, November 28, 2002 8:21 PM
> >>To: [email-masked]
> >>Cc: [email-masked]; [email-masked]
> >>Subject: Re: Multihoming with NAT
> >>
> >>
> >>Manish:
> >>
> >>
> >>I think you miss my point...
> >>
> >>To have an effective NAT arrangement where multi-homing is 
> going (i.e.
> >>you want no single point of failure):
> >>
> >>
> >>host -------nat1 ------ISP1
> >>  |
> >> +----------nat2-------ISP2
> >>
> >>Having
> >>
> >>host -----net1----NAT-------ISP
> >> |                          |
> >>+----------net2----+
> >>
> >>makes two different single points of failure .. aka the
> >>NAT itself as well as your ISP
> >>
> >>Moving the two ISPs to talk to one NAT does not
> >>help since you still have a single point of failure.. and 
> it does not
> >>work anyway.. Most nats can only handle translating to one 
> >>address... I have
> >>this arrangment in my own router/nat box... It has two ISP's 
> >>hooked to 
> >>it and
> >>I must run two different instances of the nat software.. 
> one for one 
> >>interface
> >>and the other for the second... these two do NOT know how to 
> >>communicate
> >>about the two networks...This is what is hard.. you must get 
> >>the NAT's to
> >>talk to each other and reserve the SAME port on two 
> seperate networks
> >>and setup state. There may be some nat software out there that can
> >>handle two networks but this is the rarity if it even exits...
> >>
> >>Yes it can work.. without this.. but not with multihoming in the 
> >>picture.. except maybe
> >>behind the nat (my second drawing).. and in this case it does 
> >>not really 
> >>help you
> >>that much ... and one can just do the send the INIT with no 
> >>addresses... 
> >>I don't
> >>see how you could get any benefit of the two internal 
> >>addresses without 
> >>external
> >>addresses to go with them... Remember a SCTP association is 
> >>only on ONE port
> >>and a NAT uses the ports to find the state... So my second 
> >>picture gets 
> >>NO benefit
> >>and the second requires intra-nat communications... And if 
> >>you really wanted
> >>it done right you would need to have the nats on seperate 
> boxes with a
> >>intra-nat communication protocol so you would have no 
> single point of 
> >>failure..
> >>not one nat controlling two addresses... which I don't know 
> >>if it even 
> >>exits....
> >>
> >>R
> >>
> >>
> >>[email-masked] wrote:
> >>
> >>    
> >>
> >>>hi
> >>>
> >>>No! you don't need a SCTP aware NAT, lets suppose NAT has 
> >>>      
> >>>
> >>two addresses, then
> >>    
> >>
> >>>both these addresses can be used for the  association. The 
> >>>      
> >>>
> >>packets sent by the
> >>    
> >>
> >>>peer to any of these addresses will be routed to the sctp 
> >>>      
> >>>
> >>host which has got a
> >>    
> >>
> >>>single address. So u have a multihomed association without 
> >>>      
> >>>
> >>the host having more
> >>    
> >>
> >>>than one address.
> >>>about the misbehaving routers, i'ld like say that its the 
> >>>      
> >>>
> >>multihoming that comes
> >>    
> >>
> >>>to rescue when you have diffrent addresses belonging to 
> >>>      
> >>>
> >>different networks, So
> >>    
> >>
> >>>while one network is not in good health the packets can take 
> >>>      
> >>>
> >>diffrent route to
> >>    
> >>
> >>>reach destination.
> >>>Its just that the INIT/INIT ACK chunks that communicate the 
> >>>      
> >>>
> >>addresses to the
> >>    
> >>
> >>>peer and if we can send a hostname, we can create the 
> >>>      
> >>>
> >>multi-homed association.
> >>    
> >>
> >>>Only restrition I see is dynamically adding or delteting IP 
> >>>      
> >>>
> >>addresses from such
> >>    
> >>
> >>>an association.
> >>>
> >>>And if NAT is sctp aware, which is least likely, you don't 
> >>>      
> >>>
> >>even need the
> >>    
> >>
> >>>hostname as the NAT can itself  translate the addresses in 
> >>>      
> >>>
> >>INIT/INIT-ACK.
> >>    
> >>
> >>>So  we don't require anything new from existing NAT box, all 
> >>>      
> >>>
> >>that is required is
> >>    
> >>
> >>>to send a hostname in the INIT/ INIT ACK that will be 
> resolved to the
> >>>address(es) of NAT. So probably a new interface that allows 
> >>>      
> >>>
> >>a user to specify a
> >>    
> >>
> >>>hostname for a socket to bind to. If the NAT io
> >>>
> >>>regards
> >>>manish
> >>>www.hssworld.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>[email-masked] on 11/28/2002 06:03:35 PM
> >>>
> >>>To:   Manish Rajpal/HSS@HSS, [email-masked]
> >>>cc:   [email-masked]
> >>>
> >>>Subject:  RE: Multihoming with NAT
> >>>
> >>>
> >>>
> >>>
> >>>    Hi!
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>hi,
> >>>>
> >>>>I don't think so, multihoming can work very well behind a NAT
> >>>>too. if NAT can
> >>>>translate one address, it can translate n addresses. I don't
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>    I think this is precisely the problem... NATs don't 
> >>>      
> >>>
> >>know anything about
> >>    
> >>
> >>>SCTP, so at most they can translate the source address of 
> >>>      
> >>>
> >>the IP packet. All the
> >>    
> >>
> >>>deployed NATs are not ready to recognize Protocol Number 132 
> >>>      
> >>>
> >>and then look
> >>    
> >>
> >>>inside every of such packets and recognize an INIT/INT ACK 
> >>>      
> >>>
> >>chunk, so it can dig
> >>    
> >>
> >>>inside the packet and recognize de address parameters...
> >>>
> >>>    Of course, if you re-code a NAT to do such thing, I 
> >>>      
> >>>
> >>think it would work...
> >>    
> >>
> >>>:-/ But, who is the one that is going to re-code all the 
> >>>      
> >>>
> >>existing NATs...?
> >>    
> >>
> >>>    Besides, I don't really think that having multihoming 
> >>>      
> >>>
> >>while being behind a
> >>    
> >>
> >>>NAT is really anything useful... I'm not an expert, but I 
> >>>      
> >>>
> >>would say that you
> >>    
> >>
> >>>normally have only one NAT that is "covering" a stub domain. 
> >>>      
> >>>
> >>It means that all
> >>    
> >>
> >>>the packets have to go anyway through the NAT... Well, you 
> >>>      
> >>>
> >>can always have
> >>    
> >>
> >>>several netwok cards, and then multihoming would prevent 
> >>>      
> >>>
> >>failure if one of the
> >>    
> >>
> >>>cards itself fails, but it won't prevent about misbehaving 
> >>>      
> >>>
> >>routers in the way...
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>>>foresee any issue.
> >>>>In fact, with NAT, its possible that a host running sctp and
> >>>>having single
> >>>>address can appear as a multihomed host to the peer. Only NAT
> >>>>box has to Map
> >>>>both the external addresses to a single internal address.
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>    But it has to be able to do so... which is not true so far...
> >>>
> >>>    BR Iv
> >>>
> >>>-------------------------------------------------------------
> >>>      
> >>>
> >>-----------
> >>    
> >>
> >>>án Arias Rodríguez
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>regards
> >>>>manish
> >>>>www.hssworld.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>"Randall Stewart (cisco)" <[email-masked]> on 11/28/2002 
> 01:09:00 AM
> >>>>
> >>>>To:   Manish Rajpal/HSS@HSS
> >>>>cc:   [email-masked]
> >>>>
> >>>>Subject:  Re: Multihoming with NAT
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Doing this in the kernel is very very difficult.. (see my
> >>>>earlier email on
> >>>>this subject).
> >>>>
> >>>>To get by a nat one can always just send a INIT with no 
> addresses...
> >>>>After all multi-homing behind a NAT is not going to work anyway..
> >>>>
> >>>>R
> >>>>
> >>>>[email-masked] wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Hi
> >>>>>
> >>>>>The socket draft - 04 no-where specifies an option for user
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>to provide a
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>hostname for an address. This
> >>>>>creates a problem when a multi-homed endpoint is behind a
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>NAT. As discussed in
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>sctp applicabilty
> >>>>>statement, this requires a hostname to be sent in INIT/INIT ack.
> >>>>>My question is how to get a hostname for the address
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>provided in sctp-socket
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>interface.
> >>>>>
> >>>>>regards
> >>>>>manish
> >>>>>www.hssworld.com
> >>>>>
> >>>>>DISCLAIMER: This message is proprietary to Hughes 
> Software Systems
> >>>>>Limited (HSS) and is intended solely for the use of the 
> individual
> >>>>>to whom it is addressed. It may contain  privileged or 
> confidential
> >>>>>information  and should not be circulated or used for any
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>purpose other
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>than for what it is intended. If you have received this
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>message in error,
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>please notify the originator immediately. If you are not 
> >>>>>          
> >>>>>
> >>the intended
> >>    
> >>
> >>>>>recipient, you are notified that you are strictly prohibited
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>from using,
> >>>      
> >>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>copying, altering, or disclosing the contents of this
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>message. HSS accepts
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>no responsibility for loss or damage arising from the use of
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>the information
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>transmitted by this email including damage from virus.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>--
> >>>>Randall R. Stewart
> >>>>ITD
> >>>>Cisco Systems Inc.
> >>>>[email-masked] 815-342-5222(cell) or 815-477-2127(office)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >>-- 
> >>Randall R. Stewart
> >>ITD
> >>Cisco Systems Inc.
> >>[email-masked] 815-342-5222(cell) or 815-477-2127(office)
> >>
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 03 Dec 2002 16:37:41 -0600

Some general comments on this issue...

>From a technical standpoint, almost everyone agrees that NAT is evil, messy, and painful
to accept since it breaks many app protocols. But in reality, without NAT as an effective
and practical way for boundary protection, the whole IP technology would probably lose a
big chunk of its commercial appeals - many companies would become very reluctant to even
consider putting anything of value onto the Internet (less of a concern if you are a
university). If this were to happen, every company betting on the growth of IP (especially
the network gear makers) would suffer the most... In short, NAT has a strong commercial
interest behind it and it is going to stay and we have to learn to live with it.

Therefore, I'd encourage more discussions and ideas on how to make SCTP work with NAT (I
know there are a lot of tech and impl details and challenges). But to simply say SCTP is
not going to support NAT probably is not good, since it would cut out a huge piece of
commercial value of SCTP as a real world technology. In fact, one of the biggest
incentives for a commercial application to move from TCP to SCTP is to gain path
robustness via multi-homing. If we tell them "to use SCTP you cannot have both
multi-homing and the ability of using NAT to protect your networked assets", many would-be
SCTP users would be disappointed.

-Qiaobing

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 03 Dec 2002 18:38:48 -0600

On Tue, 03 Dec 2002 16:37:41 -0600, Qiaobing Xie <[email-masked]> wrote:
> From a technical standpoint, almost everyone agrees that NAT is
> evil, messy, and painful to accept since it breaks many app
> protocols. But in reality, without NAT as an effective and practical
> way for boundary protection, the whole IP technology would probably
> lose a big chunk of its commercial appeals - many companies would
> become very reluctant to even consider putting anything of value
> onto the Internet (less of a concern if you are a university). If
> this were to happen, every company betting on the growth of IP
> (especially the network gear makers) would suffer the most... In
> short, NAT has a strong commercial interest behind it and it is
> going to stay and we have to learn to live with it.

Qiaobing, I believe that you are conflating firewalls with NAT.  The
fact is that thousands of companies HAVE put large amounts of valuable
commercial material on the Internet without the use of NAT.

Having said that, I do need to agree that NAT has strong commercial
value and that it isn't going to go away anytime soon.  Ideally, we
should see NAT wane as IPv6 waxes, but that is a slow process at
best.

> Therefore, I'd encourage more discussions and ideas on how to make
> SCTP work with NAT (I know there are a lot of tech and impl details
> and challenges). But to simply say SCTP is not going to support NAT
> probably is not good, since it would cut out a huge piece of
> commercial value of SCTP as a real world technology. In fact, one of
> the biggest incentives for a commercial application to move from TCP
> to SCTP is to gain path robustness via multi-homing. If we tell them
> "to use SCTP you cannot have both multi-homing and the ability of
> using NAT to protect your networked assets", many would-be SCTP
> users would be disappointed.

NAT IS NOT A SECURITY TECHNOLOGY.  There are people who try to use it
that way, but that is not why it exists, nor why it has commercial
significance.  NAT exists because of hysteria surrounding IP address
depletion.

Keep in mind that the path robustness in SCTP can be asymmetric.  You
can replicate network connectivity for high risk centralized
components (like servers), and still have your low risk distributed
components (like clients) singly-homed.

It is critical that we make it practical for a host behind a NAT box
to make a single-homed SCTP connection to a multi-homed peer.

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.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 04 Dec 2002 07:22:40 -0600

>interest behind it and it is going to stay and we have to learn to live with it.
Q:

I am surprised by your statements above... in particular you are echoing 
a myth that I think
many companies hold that is just not true... i.e. a NAT provides some 
kind of security. This
is far from the truth but an unfortunate illusion that many people have. 
NAT's provide NO
security.... firewalls do but not NAT's...

>SCTP users would be disappointed.
I have never stated the above... Yes we can use multi-homing with SCTP 
and NAT's but
no matter how it is done, NAT's will need to be changed to have 
intra-nat communication
or some other mechanism to setup state between two nats. If you truely 
want multi-homing
you must take out of your picture the single NAT that serves as a single 
point of failure...

So once you have two NAT's you must have some changes to them that would 
therefore allow
one NAT to setup state in the peer NAT. This could be a Application 
Gateway of some sort but
in order to preserve the "no single point of failure" that you want to 
get with multi-homing you
can't have a single ALG... thus no matter how you look at it code must 
be put in somewhere
to accomplish this setup.. You can veiw the ALG as part of the NAT (as I 
 do) or as a seperate
process running .. but it makes no matter how .. it must be one ALG for 
every NAT in order
to gain the benefits of multi-homing...

Now once you go in to modifying NATs (adding ALGs or whatever you want 
to call it) you thus
have changes you are putting in to support the state setup in two NATs 
to allow each of
them to "know" about a set of traffic going though the "multi-homed" 
endpoint. This work
must be done plain and simple..

The host-name address does not add anything to this venue. The NAT 
changes must go
on to make things work...

When you get in to changing the NAT's you then look at what is easier to 
do? Support
a dual-DNS arrangment and host-names plus all the respective code that 
is VERY hard
to implement in kernel land for SCTP to do lookups... or just to have 
the NAT munge
the INIT packet and translate all addresses in INIT/INIT-ACK...

The sheer volume of code and complexity needed tells me the far simpler 
course is to
hack the NAT's only... doing anything else is unrealistic... and 
actually the nat
coding to doe these types of changes is a small amount of work in 
relative comparison to
what the host-name would require both within NAT and within SCTP 
implementations.

There is no gain to doing host-names that I can see... NAT's will need 
to change
no matter if host-names were used or not in order to support SCTP 
multi-homing.. this is
just a sad fact of life (and yes you can call it a ALG change or 
anything else you
want.. but changes will be necessary)..

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 04 Dec 2002 07:25:06 -0600

>should see NAT wane as IPv6 waxes, but that is a slow process at
I agree 100% :>

>components (like clients) singly-homed.
Here also I agree with you.. and the good news is that we already have
a workable arrangement for NAT's and SCTP. If you do NOT send
any addresses in your INIT/INIT-ACK you will work with NO problem
when you go through a NAT...

R

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 04 Dec 2002 12:48:37 -0600

Hi, Randy,

By "NAT" I did not mean the specific "address translation" function. Instead, I
used the term to refer to a group of related gateway functions (e.g., addr
translation, firewall, visitor gateway, web proxy, content caching server, etc.),
i.e., all those middle boxes that involve in address/port manipulations. SCTP
multi-homing poses a general and common challenge to all those boxes. 

And the "include no addr in INIT/INIT-ACK" approach may be a good short term
solution and acceptable in some situations, but it does remove SCTP's multi-homing
advantage. I don't want to tell people there should not be a long term solution
that can support full multi-homing SCTP associations across those middle boxes. 

I agree that having a multi-homed SCTP association going through a single
NAT/middle-box is not the best thing, but it is still far better than not to have
multi-homing. True, the box would become a single point of failure in the path of
the multi-homed association, but if you fall back to single-homed association,
every point along your path would become a single-point-of-failure.

-Q

---

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)

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

---

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

On Wed, 04 Dec 2002, Qiaobing Xie wrote:

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

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 06 Dec 2002 07:34:31 -0600

>multi-homing poses a general and common challenge to all those boxes. 

Ok, so if we are talking on a broader sense lets talk about each on you 
mention:

1) firewall - A firewall that is NOT a NAT poses a similar problem to NAT in
    that a pair of firewalls must make sure a hole is open for outbound 
connections.
    Unless of course it is a single point of failure type firewall and 
then it would need
    to either (A) open a hole for the ports on all addresses... a simple 
approach but
    effective since the inside box would dump silently packets without 
the right vtag  <or>
    (B) inspect the INIT and use the addresses in the INIT to open the 
firewall .. the
     safest way of course .. or (C) if you had a hostname address you 
could lookup
     the name... two points about this.. the peer must have bound all 
the names in
     the name/address translation list.. otherwise this is no different 
tha (A) in leaving
     address/ports open that will be mapped... in fact this will 
actually add to the
     nightmare of implementing this thing (now that I think on it).. 
when you bind
     you need to somehow bind to that name or all the IP's of the 
name... which means
     binding must also do this translation.. (back to the firewall 
talk)... but one thing
     to also note about approach (C) is it does NOT save the firewall 
any work over
     approach (A).. the firewall must still look through the 
INIT/INIT-ACK and find
    the address type "hostname".. aka it must be aware of SCTP chunk 
formats TLVs
    and all that... This is also true for NAT's by the way, since you 
must find the hostname
    parameter... slice it any way and it means changes to NAT's and 
firewalls..

2)  visitor gateway - well I am not sure what this is so I will skip 
this.. maybe you
      can enumerate what this does..

3) web-proxy - This on the other hand I know :> and in this case it is 
proxy'ing for
    you. It poses no issue with m-homing.. if it is multi-homed.. fine 
.. if it is not well
    thats ok too. Now if it is a transparent proxy .. aka a content 
caching server or
    one that grabs all packets and then pretends to be the remote end .. 
this is still
    not a problem.. since it can respond back as the web server as a 
singly homed
    entity... the client can be multi-homed no problem. What you lose 
here of
    course is the multi-homed CNN server... but of course you are 
accessing the
    data on the proxy and NOT the server anyway.. if the proxy needs to 
go get
    content it can still be multi-homed in its download and it can talk 
to the
    multi-homed CNN server ok...

So really the big issue is <1> which leads us back to NATs etc.. and a 
couple of
important nuggets this email as made me think of:

A) binding and hostnames poses issues.

B) No matter if hostnames are used or not.. the guy dealing with them 
(firewall NAT etc) MUST
     understand SCTP INIT/INIT-ACK formats.. it needs to parse TLV's to 
look for an address
      type... this means software changes...

B above especially convices me that that hostnames are of minimal value...

R