Subject: AW: [NSIS] Some questions about the NAT/FW NSLP

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 2 May 2006 13:29:06 +0200

Hi Jukka, 

please find some comments below: 

> Hi,
> 
> Two comments below:
> 
> On Mon, 1 May 2006, Hannes Tschofenig wrote:
> 
> > Hi Jukka,
> > 
> > please find my response below:
> > 
> > Jukka MJ Manner wrote:
> > > Hi Hannes, see below
> > > 
> > > On Sun, 30 Apr 2006, Hannes Tschofenig wrote:
> > > 
> > > 
> > > > Hi Jukka,
> > > > 
> > > > a short feedback:
> > > > 
> > > > Jukka MJ Manner wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > while reviewing the NAT NSLP, several questions emerged:
> > > > > 
> > > > > A. Does proxy mode for DS (3.8.7.1) work if you have 
> more than one
> > > > > inbound
> > > > >  route? A multihomed NF.
> > > > 
> > > > Yes, It works if the edge device is a NAT. With a 
> firewall there might be
> > > > a
> > > > problem if the DS does not send an NSIS message. The 
> edge-firewalls would
> > > > have
> > > > to use a firewall synchronization protocol. We noted 
> this issue in the
> > > > appendix of the draft.
> > > 
> > > 
> > > 
> > > [JM]: Which NAT or FW do you send the messages? If you 
> have several routes,
> > > and each route has its own NAT and/or FW, then how can 
> you signal the right
> > > one? E.g. get a NAT binding for the NAT that actually 
> will be receiving your
> > > inbound traffic.
> > 
> > The message is sent towards an "opportunistic address". The 
> message just needs
> > to reach the edge-NAT/edge-Firewall and there it is not 
> forwarded further.
> > 
> > It is necessary to differentiate between REA and REA-Proxy. 
> REA just enables
> > NSIS signaling messages to traverse the edge device and to 
> give the end host a
> > contact information (i.e., a publically reachable IP 
> address) -- in case of a
> > NAT.
> > 
> > REA-Proxy does more since it also initiates a CREATE 
> message exchange
> > downstream if the DS does not support NSIS (or might not 
> support NSIS).
> > 
> > If there are multiple firewalls between the edge device and 
> the DR then either
> > the CREATE message triggered by the DS or the CREATE 
> message triggered by the
> > edge-NAT/edge-Firewall will establish the packet filter rules.
> > 
> > Does this help?
> 
> [JM]: My point is, what is this "opportunistic address"? How 
> do you know
> where is/are your NAT/FW device(s)? If you have several 
> NAT/FWs, does GIST
> provide a way to send to multiple destinations?

Ok. Let me provide a longer answer to your question. 

The main problem we want to address is end-to-end connectivity. This is
something all future Internet architecture proposals worry about in some
way or the other and they provide different solutions as well. Let us
pick more solid and more traditional proposals:

* STUN/TURN

These proposals assume that the STUN / TURN server is in the public
address space. 

* Hi3

A DHT is located in the public address space and end hosts need to
register their triggers (sort of contact information) into these Hi3
nodes. 

* Mobile IP

The Home Agent is in the public address space with the home address as
the globally reachable IP address.

* HIP RVS

The address of the rendezvous server (RVS) is stored in the DNS server
and is publically reachable. The end host registers its host identity in
the RVS. 

We make the assumption that the opportunistic address is an publically
reachable IP address but do not specify further where this address comes
from since the message should, in the normal case, never reach the
interface behind this address. As such, we are not that far away from
other protocol proposals. 

When this REA message (that is sent to such an opportunistic address)
reaches the edge-NAT then a NAT binding is created
the contact address is returned to the end host. As such, inbound
traffic WILL hit this NAT since that's the address that will be
advertised with an application layer protocol. With a firewall the
situation is different since there will be no guarantee that the traffic
will actually traverse the firewall, if the network is multi-homed and
state synchronization is not used. In this case the problem is only
problematic if the DS does not initiate a CREATE message towards the DR.

> > > 
> > > 
> > > > > B. Should the TOS byte be also available as a field 
> for matching
> > > > > traffic?
> > > > 
> > > > I still remember your old issue
> > > > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46.
> > > > 
> > > > I personally would like to see it as an extension 
> because I want to finish
> > > > the
> > > > document and it is, in some sense, an extension to the 
> base protocol from
> > > > a
> > > > functionality point of view.
> > > 
> > > 
> > > [JM]: I see this as network resource protection: you want 
> to be sure no one
> > > is trying to get an unfair treatment for his traffic.
> > > 
> > 
> > I also see it as a useful feature but we shouldn't dump 
> everything in the base
> > protocol.
> > 
> > > 
> > > 
> > > > > C. Should there be a rule for modifying a packet? Now 
> we "allow" or
> > > > >   "deny", but about also "modify"?
> > > > 
> > > > What is the scenario? I guess you are talking about a 
> "rewrite" DSCP value
> > > > or
> > > > something along these lines.
> > > 
> > > 
> > > [JM]: Yes, rewrite of the DSCP value. Still, you can also 
> do it for the TTL.
> > 
> > Could you elaborate your TTL rewrite scenario a little bit further?
> 
> [JM]: Well, you can modify the TTL value in order to prohibit, e.g., 
> traceroute-type of behavior on both directions. Of course 
> this could be a 
> default behavior, which could be hard coded, too.

We provide this functionality with the combination of "ICMP Types
Object" and the "Extended Flow Information Object". 
Nothing else is needed from this point of view. 

> > 
> > > 
> > > 
> > > > > D. Should there be a "log" action to store 
> information about certain
> > > > > packet flows?
> > > > 
> > > > Not in the base protocol. There are several problems 
> with it and it some
> > > > sense
> > > > that's what the Meeting NSLP does. If you read the 
> M-NSLP draft then you
> > > > will
> > > > notice the types of problems you suddenly have to deal with.
> > > 
> > > 
> > > [JM]: Haven't read it for a while, I'll check that when I 
> get the spare
> > > time.
> 
> 
> Jukka

Ciao
Hannes

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