Subject: [NSIS] Thoughts on unifying REA and REA-F without proxy

From: Martin Stiemerling <[email-masked]>
Date: Sat, 18 Feb 2006 11:25:03 +0100

Dear all,

Here are some thoughts on unifying REA and the REA-F w/o proxy part
(the REA-F part to tell upstream firewalls about the willingness to
accept NSLP messages).

REA and REA-F do actually share most of their semantics; both
run upstream, need to find the edge-device (i.e., edge-NAT or edge- 
firewall)
and tell the edge-device about their willingness to receive NATFW NSLP
signaling. Note that REA-F can do a blocking of data traffic as well.
REA reserves an IP address and, if applicable, a port number, at the
edge-NAT, in addition to letting corresponding NSLP signaling through.

The main difference between REA and REA-F is the message routing
part:
- REA uses LE-MRM, where the signaling destination is not necessary
the data sender's IP address. This supports SIP-based communication
where a publicly reachable IP address/port is needed right at the
beginning without knowing the other side's contact data. In general,
the LE-MRM's destination-address is set to an arbitrary address
somewhere in the Internet. The message is routed downstream.
REA reserves at NAT resource and allows incoming NSLP messages to
be forwarded to NI+/NR.

- REA-F uses PC-MRM routed upstream and needs a specific sender's
IP address in most cases (in the case of one default route from the
Internet to the end host, this address can be a wildcard). REA-F
faces tough challenges in multihoming environments, in environments
with no default route from the Internet to the end-host, or
with asymmetric routes (this will be addressed in an applicability
statement, issue 52).
REA-F allows incoming NSLP messages to be forwarded to NI+/NR
or blocks incoming data traffic (for allow-all firewalls)

Pros of separated REA and REA-F
- clear separation between firewall and NAT functionality (which is not
the case for CREATEs and actually nodes should not care about
whether to see a NAT or firewall when they start signaling)
- clear separation of message routing method

Cons of separated REA and REA-F
- end host needs to know about its situation, whether it is located
behind a firewall and NAT
- end host needs to know whether the edge-device is a firewall or NAT,
depending on this he must send REA-F or REA. In the case of
an edge-firewall, a NI+  must first use REA to edge-NAT, to get the
NAT bindings and the forwarding (multiplexing) information for the
NSLP. Afterwards, the NI+ must use REA-F to signal to the edge-
firewall

The separation has more cons than pros -- so lets unify them.

The proposal:
- Only a RESERVE-EXTERNAL-ADDRESS (REA, because the name is nice
and even in the firewall case you are reserving (in a broad
scope) an external address.
- REA is doing this:
    - At edge-NATs: Reserving external IP address/port and
    allowing NSLP messages to be forwarded.
    - At edge-Firewalls: Either allowing NSLP messages to be
    forwarded or blocking incoming data traffic (semantics
    depend on the extended flow information object).
- REA for edge-NATs can be transported over LE-MRM or PC-MRM.
(LE-MRM if DS is not known, PC-MRM if DS is known)
- REA for edge-Firewalls must be transported over upstream PC-MRM.

Corner-case: You are in NAT-ed network and the edge-device is
not a NAT but an edge-firewall (of course you do not know as
NI+ :). Processing rule for the NAT: Forward REA to the edge-firewall.
If routing fails, because there two or more boxes and you do not which
of them is the right one: Return error.

Martin

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

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 20 Feb 2006 14:04:27 +0100

Hi,

I will assume lazy consensus on this item, if there is no response
until Tuesday, Feb 21th, 2pm CET.

   Martin