Subject: [NSIS] GIST (NTLP) WGLC Comments

From: "Ford, Alan" <[email-masked]>
Date: Tue, 1 May 2007 23:12:41 +0100

Hi all,

Below, please find my initial WGLC comments for the GIST draft. I have
studied in detail sections 1-6, and loosely read the rest. I would like
to finish the rest, as well as provide some suggested text for some of
my comments. However, my progress was delayed by some interop
preparations. I shall provide further comments later. It's possible that
some of these comments are inconsistant due to reading this in multiple
sessions, however I hope they are broadly coherant.

The vast majority of these comments are requests for clarification.
Anything else is (hopefully) tagged appropriately.

Section 1:
  * [My understanding? - Not really a text change] Why does it exclude
end-to-end higher layer signalling? If all nodes were  both GIST and
application aware, would it work...? What extensions would be needed?

  * (Penultimate paragraph) - "Parts of the GIST design depend on the
use of packets with IP options"- not "depend",  something less strong.

  * (and elsewhere) - Normative reference [14] to long expired draft!

Section 2:
  * I don't feel that "Session" is defined well. I think the distinction
between "flow" and "session" needs to be better  explained.

  * "Session Identifier": "opaque" is not clear - opaque to what? (GIST,
I know, but it should say this)

  * In "sender", "aggregate" is mentioned. Adding "(subnet)" would make
the implementation clearer.

  * A definition of "routing state", e.g. "knowledge of adjacent peers
for sessions" would be useful.

Section 3:
  * 3.2, Connection Mode: "fast state setup" ??? What state is being
setup fast here? Or is the point the second bit -  reliability?

  * 3.2, UDP as "NAT-friendly" is not really explained. Is the intention
something along the lines of, "a well-known protocol  that can be
handled by aware NATs"?

  * 3.3, No mention is made of "loose end" being in the spec.

  * 3.4, first paragraph, "In addition...": a) "these messages" - not
all; b) this whole sentance is effectively repeated  later on in the
next paragraph, could just remove it.

  * 3.4, Data could be "sent in the same was as the Query", this implies
Q-Mode, is this correct?

  * 3.6, No mention is made of RAO. While this is fine, it leaves the
reader with some questions later on. Its existance  should be introduced
here?

  * 3.9, a random SID isn't down to GIST it's down to the NSLP surely...

  * 3.9, GIST should provide... "the authenticated identities used to
the signalling application". I don't see how this is  done in the API,
is this correct?

  * 3.10 2: Last sentance, "node-level policy interactions...". What is
this? Is this something else? Is this not just the  transfer attributes,
as already mentioned?

  * 3.10 4: Commentary on RAO implies requirement, needs to be updated.

Section 4:
  * 4.1.1, "how the message should be routed" add "(the flow
information)" or similar

  * 4.1.1, discarding unreliably delivered messages and telling the
sender. Is this any more than letting the TCP stack  realise it hasn't
got an ACK?

  * 4.1.2, "If there is a chance that the message was not delivered..."
we should tell the NSLP. It does not explain how, and  also, how could
this actually happen? A reliable transport mechanism, by definition,
should not allow this, surely?

  * 4.1.2, about Security, a small comment on Integrity/Confidentiality,
as mentioned in Appendix A, would be good.

  * 4.1.2, I'm really confused about "Local Processing" attributes. It
sounds like they are local only, but still I find the  purpose unclear. 

  * 4.1.2, a general comment on Transfer Attributes (also relevant in
other sections). Does "false" mean, "I do not NEED this  feature", or
does it mean "I do not WANT this feature"? It is simpler to implement
the former, e.g. provide security even if  it's not asked for. But is
that the right way to do it? This should be addressed. Especially
because this could lead to an  NSLP not being able to ask for a
non-secure MA. Sure, why would they want this? But forbidding this makes
me feel uneasy.

  * 4.2, last paragraph. Add "e.g. TCP port numbers" or similar

  * 4.3, "router alert" is mentioned explitictly in the diagram

  * 4.3, [Error?] are "Receive" and "Transmit" the right way around?
Because if they are, I'm confused.

  * 4.3.1 should also mention the later Q-Mode stuff about being able to
negotiate with peers if you know you don't use RAO,  or at least
reference the section

  * 4.3.1, last paragraph (GIST Hop Count):
    * Decrement before being passed to NSLP? Say this explicitly.
    * You should say you do not decrement if you are just forwarding it
on (I presume you don't, since you're not supposed to  look beyond the
NSLPID in that situation).

  * 4.3.2, what if it's the last hop, so GIST "MUST" peer, but the NSLP
says not? GIST can't "MUST propogate".

  * 4.3.2, how do I "flag to the receiving NSLP that the routing state
was not validated"?

  * 4.3.2, it took me a little while to realise the difference between 2
and 3 here (MA vs non-MA), maybe could be clearer?

  * 4.3.3, "forwarded within the GIST" - I presume this means just
unknown NSLPIDs. If this means anything more, please  clarify!

  * 4.3.3, "signalling application has requested " insert: 'security
attributes that require' "channel-secured delivery",  because it's not
explicitly requested as such, right?

  * 4.3.3, [Typo] "(Section 5.3.2)" is in brackets

  * 4.3.4 #1, useful to reference 3.6

  * 4.3.4 #5, why is a special mention made to not intepreting MRI/SID
from original message? This is the default for error  behaviour surely?

  * 4.3.4, the text after the numbered list, beginning "In cases (2) and
(3)...", I feel should be included into the list  itself. It is
confusing being separate. In addition, what should happen with the GIST
Hop Count here?

  * 4.3.4, #1, "The message is so large...". This sounds like a MA
should be set up on an error?! Is this right? Doesn't  really match into
state machines etc... Could be excused as a special case, but this
should be made clearer here if true.

  * 4.4.1, "...with additional payloads." Payloads makes me think of
data. Is "fields" more appropriate?

  * 4.4.1 says The peer address should be derived from the NLI "if this
was decoded successfully". If it wasn't, surely this  would be a bigger
problem and the message wouldbe errored?

  * 4.4.2, this whole text is quite tricky to follow. I realise it's
trying to be generic, but some references to TLS X509  might be useful,
and especially the concept of certificates signing keys. Will try to
look again.

  * 4.4.5. [Issue] I would like to see a way of rejecting unreasonably
long or short MA-Hold-Times and Routing State validity  times. Else we
are left with a potential DoS route. Some kind of error?

  * 4.4.6, last bit, note on responding node deletes all state if it
gets a Confirm or Data with no Routing State. Is it  possible for a race
condition to occur when one turns up with incorrect routing state and
kills the valid state that exists?  This probably could not happen, I've
probably misunderstood, just checking...

Section 5:
  * 5.1, first paragraph, should reference Appendix A.

  * 5.1, re recent discussions on list. Is it worth rewording so that
data "MUST" be carried last, and all other fields  "MUST" be carried in
order. Thus allowing intermediate extensions if required.

  * 5.1, there's a MUST NOT, should the error be explcitly mentioned
here or is it implied?

  * 5.2.2, NLI stuff - some clarification needed on upstream, previously
mentioned.

  * 5.3.1 (and Appendix A): [Issue] "Missing Magic Number" error is
infeasible, as per earlier discussions; please remove.

  * 5.3.2, IP options "(unless negotiated otherwise)"

  * 5.3.2.2. [Issue] NAT in IPv6? That does not exist, at least in
v4-style. If the comment about "legacy NAT detection" is  being made in
another context, that should be clearer, else it should be removed.

  * 5.3.2.2, [Issue] why are we forbidding any extra extension headers?
Surely this is a bit restrictive?

  * 5.3.2.3, [Typo] third paragraph, typo "networ". Also some
repetition.

  * 5.3.2.4, [Issue] says IP options are passed to NSLP, however no
provision in Appendix B is made for this. I thought IP  options were
assitance only, and only relevant to GIST (indeed conflicts with
earlier).

  * 5.6: Error messages. It implies it must be sent over D-Mode, this is
not the case though? Plus, why not include the  NSLPID if available?
Would be feasible and maybe helpful.

  * 5.7.1, "The latter approach can be used to..." insert "can be, for
example, used to..."

  * 5.7.1, [Issue]. Relating to ealier, if TCP/TLS is a valid MA to use
for "Reliable=true; Security=false", then the  principle of "MUST NOT
have weaker security properties..." means that only TLS could ever be
reused if it existed, and TCP  could never be reused. This can't be the
intention?

  * 5.7.3, it should be clearer which transfer attributes this profile
provides solutions for.

  * 5.7.3.1, APD should be defined again.

  * 5.7.3.1, discussion of wildcarding doesn't seem to be quite right,
"*.example.com matches... *.example.com" ?

  * 5.8.1.2, S=1 is the encapsulation for first hop, and this should be
made clearer earlier in this text, both in the bullet  point list, and
further on in the text, it's only right at the end that this is
mentioned, should be earlier.

  * 5.8.1.2, [Issue] later it mentions "IP version mismatch" referring
to the interface. The definition in Appendix A has  evolved to be that
the MRI's IP version MUST be the same as the flow, this does not appear
to be the case in this text.

  * 5.8.1.3, Paragraph "It is possible...", what happens if the upstream
query is the first query, does the routing state get  overridden by the
downstream? I'm guessing yes but this should be clearer.

  * 5.8.1.3, "The DiffServ... flow label MAY" - surely this should be
"SHOULD" as per earlier for downstream. Also, RAO  should be clarified
more here.

Section 6:
  * There is a general question of error message processing, and whether
any mentions of this should be made in this section.

  * Why is tg_NSLPData and tg_RawData separate, is it just the different
state machines, [QR] vs MA?

  * 6.1, [Typo] "Rle" vs "Rule"

  * 6.2, mentions of Data in Queries. This relates to the wider issue
being discussed on the list at the moment.

  * 6.2, Refresh_QNode - should reference the section with the 1/2 - 3/4
principle

  * 6.2, No_Response - default time suggestion/reference?

  * 6.2, if Rule 3 is also the Initialisation rule, then it should be
"(re)start No_Response timer", and should be more  clearly marked as
such ("Rule 3/Initialisation:" or similar)

  * 6.3, No_Confirm - similar to above, what's a default time
suggestion/reference?

  * 6.3, and what is the Number of Responses threshold? Mention it's
local policy, and a suggested value...

  * 6.4 - In general, the difference between GIST "Messages" and
"Hellos" is a bit fuzzy at times. The second paragraph  should be split
in two, and a mention made of the tg_MAIdle timer. Plus, clarify that
this activity could be based on the MA  Hold Time, else there is no
mention of this made here.

  * 6.4, NoHello/SendHello are based BOTH on the Query/Response/Confirm
sequence, because the Confirm's MAHT overrides the  Query's. Indeed,
since Confirm is always required for MAs, it should just be
Response/Query.

  * 6.4, Rule 2. Message should be passed to QSM or RSM, not NSM. Or,
fix NSM to pass it on correctly.

  * 6.4, Rule 2. Should this also have "(re)start SendHello"? Since this
also works for moving Idle to Connected. Unintended  consequences have
not been explored yet, however, and maybe it's handled by
tg_RawData/rx_MA-Hello?

Secton 7:
  * 7.4. Dual Stack: "SHOULD" use the same IP version for other queries.
This is now a MUST, based on the Error definition in  Appendix A?

  * 7.4, Tunnelling. It is not guaranteed you can know an address is
Anycast, so you can't "MUST NOT" it. Also, why the  reference to 6to4?
Surely GIST shouldn't care where the routing is coming from, unless it
is rerouted?

Appendix A:
  * A.3.1.1: "Invalid Flag-Field Combination" error. How can this be
detected? I don't see it possible to know when this  situation occurs.
Or rather, the only case I can think of is when the packet is NOT long
enough to contain the ports when the  port flags are set. If this is the
only case it can occur in, the spec should say this.

  * A.3.4, there should be a supporting diagram for a Stack-Proposal
Profile.

  * A.4.1, "Q=1", is this check valid, based on the "be liberal in what
you accept" principle?

  * A.4.1, is there a maximum length for the Comment?

  * A.4.4.1, Error 5 cannot work, as mentioned earlier.

  * A.4.4.11: In my experience of Linux implementation, the IP TTL is
not decremented until being forwarded. Should we  intercept it, it
remains at 255. I don't know if this is standard or not, however.

Regards,
Alan

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