Subject: [NSIS] NATFW protocol/specification structure issues

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 May 2006 14:23:31 +0100

hi all,

while reading the NATFW spec, i was continually tripped over by a number
of partly editorial/partly structural issues, which made it quite hard
for me to get to grips with the protocol in a concrete way.

basically it seems to me that there is a good
*) high level description of what problem space the protocol attempts
to address and the design approach which has been taken
*) low level description of how individual messages are processed at
particular nodes

but
it's hard to understand the protocol structure at an intermediate level
-
in particular, how different messages depend on each other or have to
be processed consistently, or under what circumstances messages can be
processed totally independently. (i think this becomes most visible in
the discussion of REA-like messages that might create firewall state,
which everyone seems to find a bit confusing. it also shows up in other
ways - for example, which messages control which state, how SIDs are 
allocated, and so on.) the very start of the spec talks about there
being
two 'modes' but it doesn't really say what is the significance of
a particular mode being used (i.e. what the 'mode' concept really
means).
the document also talks about 'signalling exchanges' at several points
but doesn't really talk about what the boundaries of such exchanges
are.

[you can think of this as a comment on section 3.2. 3.2.3 describes
session lifecycles quite nicely, but the definition of a session itself
is not given there. in other places, the session definition seems to be
tied to the concept of application sessions, but I'm sure this isn't
valid in reality. For example, using a REA session as part of
speculatively
registering an external address might not correspond to any specific
application session, whereas another call flow might use both a REA
messaging and CREATE messaging - is this actually one session or two?]

i also find the NI/NI+/NR/NR+/DR/DS terminology confusing. (for example,
sometimes the term 'NSIS initiator' refers to the NI+ (see for example
the top of p41.) i also find the CREATE/REA terminology confusing as
mentioned by others, especially since the spec refers to 'request' 
messages without saying explicitly what they are (so far as I could
see).

the following is my attempt to impose such an intermediate level 
structure on the protocol. it would be interesting to know if it was
correct:

*) the NATFW NSLP uses signalling sessions to manage state at
middleboxes 

*) all the messages for a given session have the same SID and MRM/MRI
[modulo upstream/downstream setting]. the SIDs for different sessions
are
un-related.

*) a session has a specific lifetime, which is negotiated by all the
nodes taking part in the session at session creation, and can be
updated during session refresh

*) a session is iniated with a 'request' message (there are two types).
The node at one end of the path which sends the first request is called
the NSIS initiator (NI).

*) a node at the other end of the path terminates the signalling and
replies to the request with a RESPONSE message. It is called the NSIS
responder (NR).

*) all the other nodes are called forwarders (NFs).

*) for the first type of session, the request is called CREATE and
the PC-MRM is used

*) for the second type of session, the request is called REA and the
LE-MRM is used. [I know this isn't consistent with 3.8.2; however,
there are bits of 3.8.2 which I don't see how they could work in
the first place.]

*) the NSLP state data is independent between different sessions.
[Actually
I am fairly sure this is wrong. However, I cannot work out what the
dependencies are!]

Clearly this doesn't capture all the details. What I'm not sure about
is whether it is consistent with all the details for proxy mode etc.
(However, if I find inconsistencies, at least it pins down which of the
details I don't understand properly yet.) 

In particular, it doesn't mention DS/DR issues directly. As I see it,
DS/DR show up because either
- it's easy to have the first session type where NI=DS (but this is
an artifact of GIST behaviour, not fundamental to the NSLP design),
but you can try NI=DR
- you have have NI=DR for the second session type, because the case
NI=DS is pointless.

And so on...

I'll try to write up my more specific points in the near future. If
any of them don't make sense, at least what's written above may
clarify where my fundamental misunderstandings are.

cheers,

r.

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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 14:44:06 +0200

Hi Robert and All,

> for me to get to grips with the protocol in a concrete way.

Bad to know that there editorial/party structural issues BUT good to  
hear
about them :-) Thanks!

> but doesn't really talk about what the boundaries of such exchanges

You are right about the report issues.

> messaging and CREATE messaging - is this actually one session or two?]

When talking about session we always refer to signaling session. Granted
that the document is not very clear about this.
There are two sessions created when using REA and afterwards CREATE.
One for REA and one for CREATE. The NI+ may decided to uphold the
signaling session for REA or delete it immediately after having received
the CREATE message. This depends mainly on whether the NI+ is awaiting
other incoming CREATE messages.

> sometimes the term 'NSIS initiator' refers to the NI+ (see for example

I see. Do you find the terms NI/NI+/NR/NR+/DR/DS in general confusing
or just the missing good introduction and straight forward usage?

> messages without saying explicitly what they are (so far as I could

Yes, you are right. The request message is not defined. This terminology
seems to be a left over from the very beginning of the draft. Does  
anybody
mind to change from "CREATE request" or "REA request" to solely
"CREATE" or "REA"?
Since the actually responses to those messages are anyway RESPONSE
messages; so it should be clear what is meant.

> *) the NATFW NSLP uses signalling sessions to manage state at

Right.

> [modulo upstream/downstream setting]. the SIDs for different sessions

Right.

> updated during session refresh

Right.

> The node at one end of the path which sends the first request is  

Right. As said above I would favor of avoiding 'request' message and
name them directly as CREATE and REA.
NI definition is fine.

> replies to the request with a RESPONSE message. It is called the NSIS

Fine and I assume this implicitly includes to my answer about the terms
NI/NI+/NR/NR+/DR/DS. You are in favour of removing the distinction  
between
NI and NI+?

> *) all the other nodes are called forwarders (NFs).

Ok.

> *) for the first type of session, the request is called CREATE and

Right.

> LE-MRM is used. [I know this isn't consistent with 3.8.2; however,

Right.

> there are bits of 3.8.2 which I don't see how they could work in

Can you point me precisely to the part? I assume that it is either
incomplete or missing text, because this section go reworked
(heavily) between -09 and -10.

> I am fairly sure this is wrong. However, I cannot work out what the

The NSLP state data is independent for independent signaling sessions,
i.e., two CREATEs. There is dependency for REA and CREATEs, which
in my view not clearly described

> details I don't understand properly yet.)

Good to hear from you about the inconsistencies, since those issues
are hard to spot for me and the other authors. We are too deep in the
matter. Things are very clear for me but I am one of the editors...

> - you have have NI=DR for the second session type, because the case

Yep, this needs some clarifications.

> clarify where my fundamental misunderstandings are.

As said, good to hear about these issues! Actually, you have hit one
of my major concerns on document structure and terminology.
Typically, those issues are better spotted and described by people
not directly editing the document. ;-)

Many thanks!

   Martin