Subject: [NSIS] NAT traversal at the GIST Layer: which approach to take?

From: "Pashalidis, Andreas" <[email-masked]>
Date: Fri, 12 Aug 2005 16:47:33 +0200

Dear WG,

As some of you may remember, in the last meeting a question arose about
which approach(es) to use for NAT traversal at the GIST layer.
The purpose of this e-mail is for the WG to obtain "rough consensus"
about answering this question, so that the appropriate text can
be put into the next version of the "NAT traversal for GIST" draft (the
current version is available at
http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattrave
rsal-00.txt)

====

The two approaches concern GIST-aware NATs (GaNATS) only; (i.e. they do
not apply to "NSIS-unaware" NATs). I will now briefly outline the two
approaches.

1) The GaNAT includes an additional "NAT Traversal" payload into the
GIST header of the GIST QUERY, RESPONSE and
CONFIRM messages. The GIST peers either side of the NAT use the
information in this payload in order to map subsequent
signalling messages to the data flows they refer to. 

2) The GaNAT replaces GIST header fields in a way consistent with the
translation of data traffic, as necessary. The GaNAT
does this for D-mode as well as for C-mode messages throughout the
duration of the signalling session.

Note that the first approach is more closely aligned with what is
outlined in section 7.3 of the current GIMPS/GIST draft.
I will now list potential advantages and disadvantages of each approach.
Please feel free to add or delete items from/to these lists.

Potential advantages of the first approach include the following.

*) As the GaNAT has to inspect only certain D-mode GIMPS messages, the
processing overhead imposed on it is minimal.
*) The amount of per-signalling session state that the GaNAT has to
maintain is less compared to the second approach.
*) The approach works in the presence of cryptographically protected
signalling traffic.

Potential disadvantages of the first approach include the following.

*) Non-NAT GIST nodes must be NAT-aware, i.e. all GIST nodes need to
implement the mechanism that follows this approach.
*) Internal network details may be revealed to untrusted parts of the
network. This is because the original GIST header
fields remain in the message that leaves the GaNAT.
*) At some point the GaNAT installs a NAT binding for the signalling
traffic. From that point onwards, the GaNAT treats
signalling traffic like any other type of traffic. This may be an
opportunity for an intruder to inject non-signalling
traffic into the internal network in scenarios where the GaNAT also acts
as a firewall.
*)The testing of implementations (e.g. via manual packet analysis) in
complex environments may be non-trivial as the correspondence between 
signalling and data traffic is only visible in the packets that carry
the initial GIST QUERY/RESPONSE/CONFIRM messages.

Potential advantages of the second approach include the following.

*) GaNATs remain transparent to other GIST nodes. As a result, non-NAT
GIST nodes do not need to implement any mechanisms
apart from the basic GIST specification.
*) As a result of the above, cascades of such GaNATs are also handled in
a straightforward manner.
*) Testing by packet analysis may be easier as the IP header in the data
flow in consistent with the MRI in the GIST
header of signalling messages throughout the network.
*) In contrast to the first approach, the GaNAT verifies that all
signalling traffic actually carries a GIST header after
the transport layer header. This advantage should be contrasted to the
third disadvantage of the first approach.

Potential disadvantages of the second approach include the following.

*) The approach does not work in the presence of cryptographically
protected signalling traffic. This is because
the replacement of GIST header fields by the GaNAT causes cryptographic
checks to fail at the receiving GIST peer. 
*) The GaNAT has to process all (as opposed to only a small subset of)
GIST headers of signalling messages. 
*) The amount of per signalling session state that the GaNAT maintains
is larger compared to the first approach.
*) The GaNAT may be exposed to service denial attacks to a higher degree
compared to the first approach.

Both approaches are adopted in the current draft. That is, a GaNAT
implements the mechanisms that implement both approaches.
It can then adopt the correct behaviour, based on whether or not
cryptographic protection is required for the signalling
traffic between two GIST peers. If such protection is not required, the
GaNAT adopts the mechanisms that follow the
first approach; if it is, it follows the mechanisms implementing the
second approach. The GaNAT can tell whether or not
cryptographic protection is required from the stack proposals that are
exchanged in the GIST QUERY and RESPONSE messages;
inclusion of IPsec or TLS proposals amount to cryptographic protection
being required. 

For those that may want some more information in order to contribute
their view on this matter (but do not necessarily want
to read the current draft), a more detailed explanation of how new
signalling session are handled by the NAT can be found
in the "trailer" of this email.

=====
                    
Question to the WG: It remains unclear whether or not it is desirable to
specify both the above approaches 
(for example, because there may be scenarios the requirements of which
are better met by one or the other). What does the WG think.

(a) Both approaches should be mandantory to implement.
(b) One approach only should be taken (which one?)
(c) One approach should be mandantory to implement (which one?) and one
should be optional (which one?)
(d) Another approach is better (please describe the approach)

======

Many thanks for your time and response!

START OF TRAILER

The following three paragraphs clarify how the GaNAT handles new
signalling sessions and how the selection of the "correct" behaviour is
supposed to work.

Regardless of which approach is taken, after a GIST response passes
through the GaNAT, the GaNAT should expect a
messaging association to be set up between the two involved GIST peers.
For this to happen, the GaNAT has to allow
traffic to traverse it. From a security perspective, the GaNAT should
allow the minimum necessary traffic types
to traverse. Additionally, the amount of per signalling session state
that is allocated at a GaNAT should
be minimised for reasons of efficiency and resistance to service denial
attacks. For these reasons, it makes sense
for the GaNAT to be able to predict with certainty which of the GIST
responder's stack proposal will be used by
the initiator for the establishement of a messaging association. This
can be accomplished by having the GaNAT 
modify the stack configuration object in the GIST response as it passes
though it such that the initiator is forced to use
a particular stack proposal and, if applicable, a particular transport
layer destination port. 
                
The reason why it is preferable for the GaNAT to modify only the stack
configuration data object (as opposed to the
stack proposal object) is that the GIST responder expects its original
stack proposal to be included in the GIST
CONFIRM message. The initiator would not be able to echo that object as
it would not have seen it and, if signalling 
messages are cryptographically protected, then the GaNAT cannot replace
the stack proposal in the GIST CONFIRM message 
with the one the responder expect, without causing cryptographic checks
to fail at the responder. Thus, the approach taken
in this document is for the GaNAT to render invalid all but one stack
configuration data objects in the GIST RESPONSE
message. A stack configuration object is rendered invalid by setting the
port number to zero. 

A question arises due to the fact that the stack proposal carried by a
GIST RESPONSE may include multiple messaging 
associations of which some provide
cryptographic protection for signalling traffic and some do not. Which
behaviour should the GaNAT assume in this case? In
other words, which stack configuration objects should the GaNAT render
invalid in this case? The GaNAT SHOULD render
invalid all stack configuration objects except the first that refers to
a stack proposal that offers cryptographic
protection. 

END OF TRAILER

Andreas and Hannes

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

---

From: "Christian Dickmann" <[email-masked]>
Date: Fri, 12 Aug 2005 17:44:54 +0200

Hi Andreas, 

> the initial GIST QUERY/RESPONSE/CONFIRM messages.

I do not think, that there is really an issue here. 

> apart from the basic GIST specification.

I think this statement is just not true. The solution has to be flexible
enough to work in all scenarios and this includes profiles referring to
secure connections (like TCP/TLS). Your second approach does not work for
this scenario.

> should be optional (which one?)

I prefer (c). Make the first approach mandatory and the second one optional.
As said, the second one is not flexible enough to handle all scenarios, so
the draft MUST contain an alternative approach for those cases. In contrast,
the first approach works in all scenarios and therefore it should be the
mandatory one. 
But as you outlines in your analysis GaNATs might prefer the second approach
in special cases. So the draft could contain a section about this approach
and descripe roughly how it works and in which cases it is applicable. 

To summarize my opinion: My first choice would be (c) and alternatively (b).

Christian Dickmann

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 19 Aug 2005 16:39:01 +0100

hi all,

I have to say that I broadly agree with Christian's views
(in a parallel branch of this thread). But apart from commenting
on the particular issues listed below, I think there is also a
slightly higher-level perspective on the two alternatives, 
which are not really alternatives in the specification sense.

One approach is to construct a genuinely transparent NAT, which 
is not visible to the GIST nodes either side. *By definition*,
this won't have any impact on the GIST specification; people 
may implement such things and we won't necessarily even ever
know about it. [Whether we should encourage such behaviour
is another matter, which I'll come back to.] The only possible
interaction with the specification would be if there was something
we could do to GIST to make it easier to construct such a NAT;
however, we already know that there are at least some scenarios
where such a NAT cannot function, so at best we are talking about
tweaking boundaries here.

The other approach is to to have a non-transparent NAT, which
is visible to other GIST nodes and does impact the GIST 
specification. We know (to a high degree of confidence) that 
this approach can always be made to work, although some more
validation would be nice. This is the approach taken in the
current spec.

These approaches are not either/or alternatives. The 'invisible'
approach (by definition) can be developed independently, and
deployed in conjunction with the 'visible' approach. Indeed, I
would expect to see both exist. 

Apart from the specific pros/cons (commented below), which I 
have added some to, my architectural instinct is that the
'visible' approach is the better solution at least initially. 
There are three reasons:
1) We already have 'invisible' NAT approaches for existing
protocols (TCP, UDP etc.) That's all very nice and reasonable
given the fact that NATs happened after these protocols were
specified. But a huge amount of subsequent effort has gone 
into methods to make these NATs visible (STUN, TURN and so 
on). In the long term, I don't think that continually trying 
to hide NATs from (new) protocols is desirable.
2) Some NAT implementations are very good and some are not so
good; also, many end up in embedded firmware that is very 
rarely updated (i.e. bug-fixed). From that point of view, we
need to ensure that there is a NAT approach available with
the fewest possible subtleties and the least requirements 
for updates as GIST and NSLPs evolve. In other words, this
consideration tilts the balance towards putting complexity
in the GIST node rather than the NAT.
3) There is an (I think) attractive aspect of the GIST design
that all the interaction with the infrastructure lying between
the GIST nodes takes place in an integrated way, during the
3-way handshake (in fact, in the first 2 messages), both in
initial setup and also refresh. The 'invisible' approach 
complicates this, because interactions with routing and NATs
take place during the handshake, and further interactions but
only with NATs take place afterwards also. It becomes more of
a headache to keep these consistent if routing or NAT
configuration is changing. (This probably doesn't matter for
the path-coupled MRM in basic scenarios, since if the NAT 
configuration changes all the flows will fail anyway. But
for other MRMs or scenarios with distributed NATs the situation
is much less clear to me.)

More comments below,

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pashalidis, Andreas
> Sent: 12 August 2005 15:48
> To: [email-masked]
> Subject: [NSIS] NAT traversal at the GIST Layer: which 
> approach to take?
> 
> 
> Dear WG,
> 

True. (I believe the delta in functionality/load to be relatively
minor, however.)

> fields remain in the message that leaves the GaNAT.

True. This is intrinsically unavoidable if one uses peer-peer security 
protection. Also, I am not clear how strongly people care about this
level of hiding; if they do, I would have thought that they would 
also want signalling application level control at the site boundary
anyway (which may or may not be at the NAT itself).

> traffic into the internal network in scenarios where the 

I don't see the point here. If you can inject non-signalling traffic,
why not inject signalling traffic as well? In reality, if you care about
traffic injection you should be using messaging assocation security
anyway.

> the initial GIST QUERY/RESPONSE/CONFIRM messages.

Like Christian I don't really see the issue here. In either approach,
to understand the C-mode traffic, you have to follow the entire C-mode
data stream and also understand what D-mode exchanges relate to it. 

> a straightforward manner.

This is important (and needs to be verified that the 'visible' approach
has the same property, which takes a bit more work.)

> header of signalling messages throughout the network.

I'm not sure what this means?

> third disadvantage of the first approach.

The malicious person can always add a malicious GIST header if 
they want ...

> compared to the first approach.

There are a couple of extra disadvantages to be considered here.

Firstly, the GaNAT has to preserve the transport layer communications
properties provided by C-mode between the two peers, including the
operation of
- flow control (imposed by one peer on another)
- congestion control
- reliability
- and do so in the case of error conditions (connection resets) and
packet re-ordering/loss
- all the time reconstructing the data stream to do the in-stream
manipulation
This can be done in the restricted set of deployment conditions
for the use of TCP in GIST; however, no-one should be under any
impression that it is at all trivial. It's comparable to the work that
needs
to be done on the FTP control channel (and I've enough bad experience
of the decreased usability of FTP compared to e.g. HTTP behind NATs,
especially under extreme conditions.)

Secondly, the question of GIST extensions has to be considered. In the
'visible' case, the GIST peers know exactly which objects have been
translated by the NAT and which have not; if a new object is added
to GIST, which the GIST nodes understand, they can make intelligent
decisions about how to handle it when it has been carried through
a NAT (since they know what a NAT has done to it). [If they don't
understand it, the question is moot anyway.] OTOH, in the 'invisible'
approach, a GIST node has no idea whether all the objects have been
consistently processed, since it doesn't even know they have been 
processed in the first place. This is a serious problem with any
NAT approach for an extensible protocol.