Subject: [NSIS] NATFW NSLP Issues

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Apr 2006 14:44:57 -0400

Hi all,

after I reviewed the other NSIS documents I tought about some aspects of 
the NATFW NSLP draft again and I came across a few issues:
(Btw, there some QoS related aspects in there as well.)

* Section 2.7 talks about IPv4/IPv6 traversal but gives the impression
that there is only NAT-PT and it would not imply additional
considerations for the NATFW NSLP. I do agree that there are no problems
for the NATFW NSLP but I think that this is mainly due to the
functionality provided by GIST.

I wonder whether more text is needed to capture this fact.

* Section 2.8 talks about "multihomed networks". When I used the term
"multihomed network" in the past then I referred to networks that have
multiple upstream providers. Figure 9 would refer to a multi-homed host
in my terminology.

The roles of NI/NR are reversed in Section 2.8. Furthermore, I don't
think that the scenario depicted in Section 2.9 is challenging.

* In Section 3.2 I noticed a terminology confusion since we use the
term "NI" also for the DR in the REA mode.

Maybe I am the only one having problems with the terminology.

* Section 3.4 talks about Session Lifetime calculation. Some of the
parameters the calculation are not available before the
session started.

Could this be a problem?

* The QoS NSLP spec does not mandate protocol operations similar to
those described in Section 3.8. Why do we need them?

* I suggest to make it very clear that the REA mode description only
allows NSIS signaling to traverse and does not create a true NAT binding
very early in the text. The text about Proxy-REA starts much later in
the draft but I think it is really important from a deployment point of 
view.

* The QoS NSLP draft analyses route changes and mobility in some level 
of detail (see Section 5.2.5 of the 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt). 
The NATFW NSLP aspects are a little bit different than the QoS NSLP 
issues with regard to this aspect. Section 3.10 (Reacting to Route 
Changes) talks about this aspect. I would like to know whether people 
happy with the text?

* In Section 3.8.7.2 (Proxy for a Data Receiver) we assume that the
NI knows whether the message will be able to travel all the way to the
NR. Hence, we require the NI to decide whether it wants to use
CREATE or CREATE-PROXY messages. I thought that the QoS NSLP guys do not 
make this assumption.

* The usage of the NATFW_DTINFO object might require a more detailed 
description. I particularly think that the case where more than one NAT 
is present along the path is not addressed appropriately.

Text is required to state when the NATFW_DTINFO object has to be updated 
with the information obtained from a NAT binding allocated by each NAT.

The 'NATFW_DTINFO_IPv4' has to be mandatory for the proxy REA since 
otherwise the CREATE message, which is sent by the edge-NAT towards the 
DR, does not have enough information to establish a binding at a NAPT.

Here is the text from the draft:
"
    The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message
            ^^^^
    when using the LE-MRM.  The LE-MRM does not include enough
    information for some types of NATs (basically, those NATs which also
    translate port numbers) to perform the address translation.  This
    information is provided in the NATFW_DTINFO_IPv4 (see Section 4.2.7).
    This information SHOULD include at least the 'dst port number' and
    'protocol' fields, in the DTInfo object as these may be required by
    en-route NATs, depending on the type of the NAT.
"

I think that the DR MUST include the NATFW_DTINFO_IPv4 object in the REA 
message in order to provide enough information for a NAPT along the path 
towards the edge-NAT to make a reasonable decision. Hence, a MAY is not 
enough.

The NATFW_DTINFO currently talks about IPv4 only. I think that the data 
sender's address could also an IPv6 address and here is the scenario:

DSv6--|Edge-NAT_v4/v6_GW|--v4--|FW|--v4--|v4/v6_NAT_GW|--v6--|DRv4/v6|

This requires a v6 DS address in the DTINFO object.

Furthermore, I would like to comment the content of the 
NATFW_DTINFO_IPv4 object itself.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|P|S|    reserved             | sender prefix |    protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :      dst port number          |      src port number          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                            IPsec SPI                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  data sender's IPv4 address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 29: Data Terminal IPv4 Address Object

    The flags are:

    o  I: I=1 means that 'protocol' should be interpreted.

    o  P: P=1 means that 'dst port number' and 'src port number' are
       present and should be interpreted.

The 'dst port number' and the 'src port number' always appear in pairs.
Why cannot I just filter based on the DR's dst port number?

    o  S: S=1 means that SPI is present and should be interpreted.

For allow incoming IPsec traffic it is necessary to define Source/Dst IP 
address, SPI, Protocol Type (AH/ESP). AH and ESP is defined via the 
protocol field. Should we mention this somewhere or is it already obvious?

There are two objects that define packet filtering capabilities: DTINFO 
and ICMP. It is fine for me to split the functionality into two 
attributes (as it is done today). Is this OK for everyone?

* Terminology problem: We use the term 'NATFW_DTINFO_IPv4' and 'Data 
terminal information object' interchangable. This makes it quite hard to 
find the correct text in the draft. I am not sure whether we should 
change it.

* Instead of putting port information into the MRI the port info is used 
in the 'NATFW_DTINFO_IPv4' object. This prevents GIST aware NAT 
traversal to work properly. Is this a problem? I wonder what the impact 
for NSIS unaware NAT traversal is.

* I am not sure about the MRI to IP Src/Dst relationship. In some cases 
it is not quite obvious what to put, for example, in a CREATE message 
sent from the edge-NAT towards the DR. We could use the DS IP address, 
the IP address at the public side of the NAT, the IP address at the 
private side of the NAT. This might be a GIST question.

* Appendix B: DR behind a Firewall

I thought again about the DR behind a firewall scenario and I came to 
the conclusion that it is not as bad as it might seem to be.

Here are my thoughts:

If the DR creates policy rules (using proxy REA) at the edge-FW then a 
NSIS unaware DS is not able to let its data packets flow through the 
firewall (since they will hit the wrong firewall at the DR side where 
the policy rules for the data traffic are not created and the traffic is 
therefore blocked).

The edge-FW might, however, know that its own network offers such a 
deployment environment and might provide the end host with some 
information back to the DR. I could imagine something like "This network 
is multi-homed. You might encounter problems." or "This network is 
multi-homed but state-synchronized.".

If the DS is NSIS aware then a subsequent CREATE hits Firewall 2 (the 
proxy REA established policy rules at Firewall 1). This is, however, not 
a problem since this message might be able to traverse the firewall 
towards the DR anyway. The DR can then decide whether he honors the request.

As such, I think that the situation with a DR behind multiple FWs is not 
  so dramatic as it might seem to be.

What do you think? We could rewrite some paragraphs in Appendix B.

* Extensibility of the Common NSLP object header format

Section 4.2 of the NATFW NSLP addresses the extensiblity of the Common 
NSLP object header format. We might want to state that the format is the 
same as the one in Section 5.1.3 of 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt.

There is, however, a small difference. The AB=11 functionality provided 
by the draft-ietf-nsis-qos-nslp-10.txt is not offered by the NATFW NSLP:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-10.txt
"
       AB=11 ("Refresh"): If the object is not understood, it should be
         incorporated into the locally stored signaling application state
         for this flow/session, forwarded in any resulting message, and
         also used in any refresh or repair message which is generated
         locally.
"

I gave the QoS NSLP authors the feedback that I think that the semantic 
of the "Refresh" behavior is strange. We have excluded it but I think we 
should make sure that the two NSLPs are aligned. What do the QoS authors 
think?

* TRACE Message

I noticed that the IANA registry for the 'trace type' field is missing. 
Currently, only two values are defined (0x01 and 0x02) but there is 
plenty of room for extensibility. I think that there is a need to create 
a registry. Generating an error if a node does not understand a 
particular extension might make it difficult to offer some extensions in 
the future.

Section 4.2.8 says:
"
    The NATFW_TRACE object may contain zero or more identifiers of
    visited NATFW NSLP peers.  However, it is only possible to store a
    single type of identifier, either IPv4 or IPv6 addresses.
"

I think that an NSIS aware NAT/Firewall adds both interface IP 
addresses(incoming and outgoing). Would it be useful to use an 
identifier for the NSIS node (e.g., generated locally at the NSIS node, 
to identify a node again in case of route changes and mobility).

Would we like to impose a restriction regarding a single type of 
identifier? (only possible to store a single type of identifier) As 
currently specified, the mechanism cannot be used in a v4/v6 environment.

Given that the trace object is quite generic I think that it should have 
the following shape:
"
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         trace type            |           hop count           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                           Trace Values                        :
      :                               ...                             :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Btw, I wonder whether we actually need to define a separate message 
rather than attaching a Trace Object to an existing message (e.g., a 
CREATE) and then the corresponding debugging information is created.
This would make the message immediately useful for all messages (CREATE, 
REA, CREATE-Proxy, REA-Proxy).

This issue is just something for discussion.

* Usage of the "External Address Object"

The RESPONSE message may optionally carry an External address object. 
Below you can find a modified version of Figure 14 of 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt

        NI      Private Network        NF    Public Internet        NR
        |                              |                            |
        | CREATE                       |                            |
        |----------------------------->|                            |
        |                              |                            |
        |                              |                            |
        |                              | CREATE                     |
        |                              |--------------------------->|
        |                              |                            |
        |                              | RESPONSE                   |
        |                              | (External Address Object)  |
        |    RESPONSE                  |<---------------------------|
        |    (External Address Object) |                            |
        |<-----------------------------|                            |
        |                              |                            |
        |                              |                            |

            Figure 14: CREATE message flow with success RESPONSE

Now, the following question arises: Who has to add the External Address 
Object. I would argue that NR MUST add it. The NF MUST verify that the 
information is correct. Only the edge NF can truely verify it.

That's all for now.

Ciao
Hannes

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