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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 2 Aug 2006 12:09:57 +0200

Hi Matthias, All,

Am 31.07.2006 um 14:38 schrieb Matthias Friedrich:

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

I'm fine with suggestions that make the protocol semantics and the  
implementation easier. I also would appreciate a review of the  
changed text around LE-MRM and PC-MRM in the upcoming revision of the  
NATFW NSLP. The new revision will be available around early October.

Thanks,

   Martin

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 09 Aug 2006 17:24:55 +0200

Hi Martin,

Martin Stiemerling wrote:
> 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

Sorry, but I absolutely don't get it. Why doesn't the GIST node know
which route to take? So a route lookup for the prefix N doesn't succeed
in this case (no route) or returns more than one entry (should not
happen), or what? I can only imagine the "MRI too wild case",
i.e., specifying a /7 when you only have /8s or so.

So what I understand from the draft and you mail is that:
- DS is currently unknown and somewhere outside your (DRs) NATed domain.
- DR wants to do a REA first which also includes a route pinning, i.e.
  no matter which NAT your REA hits, the incoming stream from DS
  will then hit that particular NAT.
- DR sends a REA message "upstream" towards some external node
  with IP address LS (and maybe LS!=DS) behind the NAT.
  So the SDA is LS which is also used in the LE-MRM as destination.

Why, then can't we use the very same address in a PC-MRM, so
ip.src=R, ip.dst=LS,
pc-mrm.src= LS, pc-mrm.dst= R, pc-mrm.direction=upstream
pc-mrm.prefixlength=32?
So it's not a wildcarded PC-MRM. In this case I don't see
any routing problem for GIST. Or, what is the reason that we must
use a wildcarded PC-MRM?

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

I understand and this is also clear. If you vary LS, your NAT may
differ, but this doesn't matter (except for suboptimal routing)
because you pin down the route by hitting the NAT.

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

Sorry, but it's not clear to me why the LE-MRM gives more power
to hosts. If we use a PC-MRM like in the scenario above, there
will be no problem, or, can you explain once again, giving a concrete
example, why it would fail?

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

Actually the "magic" or "special power" behind the LE-MRM is
currently not getting clear. Maybe there are some implicit
assumptions that are not written down yet.

Regards,
 Roland