Subject: [NSIS] some comments on SDA selection in the NATFW NSLP

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 3 May 2006 13:34:04 +0100

hi,

these comments are mainly inspired by appendix A and the
other sections on SDA use.

to me, App A seems to make the whole problem seem much more
complicated than it really needs to be. to take the various
options there in turn:

1) seems to say 'use the DS address if it is known'. The
first problem listed is not actually a problem, just a statement
of fact about how this is done if the DS is behind a NAT. The
second problem listed I could not be certain that I understood,
but I don't really see what problem arises: it is up to the 
DS to obtain an address which is valid at the NAT it is behind,
and if it can't then no-one will ever be able to communicate
with it. If the address is valid at the NAT it is behind, then
I don't see how routing asymmetry (which is about differences
between the routing for forward and reverse traffic between two
nodes) causes issues, since the route is pinned at the NAT anyway. 
In any case, such a discussion is not relevant here; if the
DR knows the DS address, it surely just has to believe it for
the purpose of choosing an SDA. Discussing how that DS address
might not be valid at all doesn't really change that.

2) if the DR already knows its public address, then I don't see
why REA signalling is taking place at all.

3) is about using the application server address. The first problem
would seem only to arise if the DR was not behind a NAT in the
first place (in which case the DR doesn't need the REA signalling
to work); the second problem I would say is a minor issue.

What i think is missing is a overall perspective on how a NATFW
implementation is expected to/able to interact with other application
layer protocols. I'm not talking about APIs, but more abstract
points like who is expected to provide what information and when.
(This question also occurred to me while reading 2.4.) The key
point for App A is that the only reason why the DR might be 
obtaining an external address is in order to communicate it to
someone (if DR doesn't communicate the address, why bother to 
obtain it?); so the address of the person it communicates with
is surely a reasonable address to use as the SDA. It doesn't 
actually matter whether the SDA corresponds to an application 
server or a host and you could quite easily have multiple ones.
Nor does it matter which address realm the SDA is in - the implementor
just has to know that the DR will be reachable from the address 
realm in which the SDA lives, and choose the SDA accordingly.

(A problem arises if the DR only knows an SDA for a node in the
wrong address realm - for example, it can only talk to a local
SIP proxy behind the same NAT as itself. I can't think of a good
solution to that problem.)

r.

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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 15:17:50 +0200

> complicated than it really needs to be. to take the various

True.

> to work); the second problem I would say is a minor issue.

All agreed

> realm in which the SDA lives, and choose the SDA accordingly.

All right! We are going to change the section towards your
proposal of "overall perspective on how a NATFW implementation
is expected to/able to interact with other application layer protocols".

> solution to that problem.)

I can't think about a good solution to that problem either. This
falls under "choose the SDA is a wise way".

Thanks,

   Martin