Subject: Re: Multihoming with NAT

From: [email-masked]
Date: Mon, 2 Dec 2002 10:26:04 +0530

hi randall,
Yes I agree that effective arrangement will be the frst one, where you have two
external addresses. To initiate the session and create bindings, the NAT will
have to be aware of the SCTP packet format so that it can identify the INIT
chunk and reserve a port , if this is the case then one just needs an ALG that
will instruct ALL of the NATs to create bindings with the session parameters and
establish state for that session. Not expecting much from either NAT or the
ALG!!!.

host A ----------------------nat1-----------------ISP1
     |(IP A)                         (IP x1)
     +--------------------------nat2 --------------------
                                         (IP x2)

So when a INIT chunk orginating form host A with source address in IP header A,
reaches nat1, (or nat2 for that matter), the ALG instructs  both the NATs to
create bindings . Now the packets recieved from peer at either x1 or x2  will be
correcty routed to host A. The INIT chunk can not advertise the addresses x1 and
x2 beacuse they originated from the host A. So having a hostname that resolves
to x1 and x2 is the probale solution. Another thing that is possble is expecting
the ALG to modify the chunk and add/modify the addresses in it, but this would
require complete parsing, modifying and then recalculating the checksum for the
packet. Too much to ask for from an ALG.

If the NAT is not SCTP Aware, the sessions will be initiated and closed based on
heuristic algorithms.  the state at NAT will not be based on the port numbers.
Any packet from host A can initiate the session which will be purely based on
the source and destination IP address. So if the peer is multihomed that will
mean multiple states for the same session at the single NAT. I still don't see
any issues with having multihomed association where x1 and x2 both can be used
as local addresses. Again all that is required is a hostname.

regards
manish
www.hssworld.com

"Randall Stewart (cisco)" <[email-masked]> on 11/29/2002 06:51:14 AM

To:   Manish Rajpal/HSS@HSS
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)

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 02 Dec 2002 11:15:54 -0600

>packet. Too much to ask for from an ALG.

And where is the ALG in your diagram?  It either must be between the two 
nats
or be inside the nats... either way the nat's are communicating state 
between them.
This is my whole point.. NATs of today currently do NOT communicate state
between them.. they are stand alone seperate entities that know how to 
translate
a port+ip address pairs to the inside version.

Yes it is doable .. but this "nat protocol" or ALG has you call it is 
NOT defined
and must be standardized so that nat1 from company1 and nat2 from 
company2 can
do the correct thing..

All of this is bad in general.. nats are a very big evil that I see no 
use to teaching
how to do multi-homing..

Hostnames help you no more than listing the addresses and having the
nat's change them.. after communicating with each other about state
setup.

My point is that you MUST change the nats in some fashion.. in such
a case where you change the Nat the host name becomes a mote point.. doing
it with hostsnames is no advantage over just munging the INIT/INIT-ACK after
negotiation with your peer..

>a

and lots of changes to the two nats or changing a single nat to 
understand multi-homing..
in either case software changes to current nat technology.. my argument 
is not it
cannot be done.. but that nat's need to be changed if so then the 
hostname parameter adds
nothing to this..

R

R