Subject: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6

From: Matthias Friedrich <[email-masked]>
Date: Wed, 12 Jul 2006 18:32:13 +0200

Hi,

I'm wondering why there is no NATFW_DTINFO_IPv6 object in the current
draft revision (draft-ietf-nsis-nslp-natfw-12).

Suppose an NI+ is behind a firewall (no other firewalls, no NATs) and
wants to send a REA message upstream to block traffic from a range of
addresses. Then there is no known sender address, and it would IMHO make
sense to use the LE-MRM with an appropriate SDA. At least that's what I
think the LE-MRM was designed for. In the IPv6 case, a NATFW_DTINFO_IPv6
or a generalized NATFW_DTINFO object would be needed.

According to section 3.7.2, in this case the PC-MRM should be used with
the "data flow source IP address set to wildcard". I must admit I'm a
bit lost here, the "two different signaling scenarios" on page 36 are
difficult to read. Splitting the text into more paragraphs with some
more explanations would probably help.

What I don't understand is: If the PC-MRM may be used when the data
sender is unknown, why do we need the LE-MRM at all? Witout it, we would
get rid of the NATFW_DTINFO object(s) altogether.

One last thing, I heard that the REA message is going to be renamed.
It's not very creative, but why don't you rename CREATE to SCREATE
(Sender/Source CREATE) or ICREATE (Initiator CREATE), and REA to RCREATE
(Receiver/Responder CREATE)? Maybe the whole NI+/NR+ terminology could
be dropped, too.

Thanks in advance,
	Matthias

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

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 31 Jul 2006 11:33:52 +0200

Hi Matthias,

> draft revision (draft-ietf-nsis-nslp-natfw-12).

A very brief answer ahead: Because there is no IPv6 NAT and the  
DTINFO* objects are used for NAT traversal. More further down this  
email.

> more explanations would probably help.

The LE-MRM has been just defined for the NAT usage and is not  
intended for pure firewall usage. The main difference between LE-MRM  
and the PC-MRM in the NAT case is: The message can probably not be  
forwarded when the receiver is behind a NAT and it is using the PC- 
MRM with a wildcarded sender IP address. When there are multiple NATs  
in parallel to the Internet, GIST may have the issue of not knowing  
which route to take. In this case GIST would return an error message.  
By using the LE-MRM, GIST is always able to route the message  
upstream to "a" NAT. In the first place it is not necessary to hit  
the best NAT, i.e., closest to the data sender but to get a public  
reachable IP address. By choosing different SDAs, one may get a  
better or worse located NAT.

Therefore, there is a difference between using the LE-MRM and the PC- 
MRM if the data receiver is behind a NAT. For the case with firewalls  
only, as you have described, LE-MRM is not an option, but PC-MRM is.  
LE-MRM cannot be used, because GIST would route the signaling message  
towards the SDA and end up at firewall X. However, the real data  
traffic would hit another firewall Y. When there are multiple  
firewalls in parallel, this is probably going to be the wrong  
firewall and GIST has not the chance of returning an error, which  
tells "there are multiple routes and I cannot forward your message".  
By using the PC-MRM GIST can route the signaling message upstream and  
if there are multiple inbound routes, stop the forwarding and return  
an error message. In the firewall case it is not useful to hit any  
firewall, because firewalls do not do any route pinning as opposed to  
NATs.

> get rid of the NATFW_DTINFO object(s) altogether.

It is not that easy, because LE-MRM gives more power to hosts behind  
NATs. LE-MRM will definitely find an edge-NAT while PC-MRM can easily  
fail if there are multiple NATs in parallel.

However, it is time to rework the section(s) on the LE-MRM/PC-MRM  
usage (plus DTINFO) for getting it all clear. I see the issue of  
having the information about the MRM usage spread too much over the  
document and lack of some good introductory text.  There will be an  
updated text in the next version clarifying this.

I hope to get you as a review! :-)

> (Receiver/Responder CREATE)? Maybe the whole NI+/NR+ terminology could

Good proposals. I've just seen you posting to the list and the  
suggestions will taken to the list.

Thanks,

   Martin

---

From: Matthias Friedrich <[email-masked]>
Date: Mon, 31 Jul 2006 14:38:14 +0200

Hi,

On Monday, 2006-07-31, Martin Stiemerling wrote:
[ LE-MRM vs. PC-MRM etc. ]

Thanks a lot for your detailed response.

I think I understand now why the LE-MRM has been chosen, however,
I'm a bit unhappy about the special cases that have to be handled in
NATFW-implementations. Things are more tricky than I initially thought,
but maybe I can work out an alternative that reduces complexity a bit
and post it to the list in the next couple of weeks.

Cheers,
	Matthias