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

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 1 May 2006 18:05:08 +0300 (EEST)

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.

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

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

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 01 May 2006 16:31:18 -0400

Hi Jukka,

please find my response below:

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

> [JM]: Yes, rewrite of the DSCP value. Still, you can also do it for the 

Could you elaborate your TTL rewrite scenario a little bit further?

> [JM]: Haven't read it for a while, I'll check that when I get the spare 

Ciao
Hannes

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 2 May 2006 11:10:00 +0300 (EEST)

Hi,

Two comments below:

On Mon, 1 May 2006, Hannes Tschofenig wrote:

> > Hi Hannes, see below
> > [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.
> 
> 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?

> > [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.
> 
> > 
> > 
> > [JM]: Yes, rewrite of the DSCP value. Still, you can also do it for the TTL.
> 

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

Jukka

---

From: <[email-masked]>
Date: Tue, 2 May 2006 14:20:11 +0300

Hi all,

Currently, the NSIS working group is finalizing the "NAT/Firewall NSIS
Signaling 
Layer Protocol (NSLP)" for signaling middleboxes.  The current document
can
be found here:

http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt

NSIS is working on a path-coupled signaling protocol, to signal nodes
along
the data patch.  As both NAT and Firewalls are along the data path, NSIS
signaling is developing a protocol for allow end nodes to signal these
boxes.

As both BEHAVE and MIDCOM have been working on related issues, I'd like
to
encourage people to read the document and send comments and questions to
the
mailing list - [email-masked].  As long as your subject lines are clearly
marked, I'll enable posting rights so that you don't have to join the
NSIS
mailing list.

Additionally, please try not to cross-post discussion on the other
mailing
lists; unless the BEHAVE & MIDCOM chairs feel that cross-posting would
be beneficial.

thanks,
John