Subject: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Oct 2005 15:24:59 +0100

hi all,

the missing MA_HOLD_TIME is definitely a bug. 

i think the neatest solution here is to move the MA_HOLD_TIME to
the NLI as an optional field there. the Q-node NLI is repeated in
the confirm. i'd rather not repeat the whole stack-config-data,
and the stack-proposal is for the 'wrong' node anyway. this is
not quite as logically pure as the current structure, but is
probably the right compromise between purity and sophistication.
(the NLI is repeated in the confirm for precisely the reason that
the R-node will have forgotten the original, so there is a match
of purpose here). i will add a new issue for this.

for roland's other points:

- i think the case of using a 'wrong' MA configuration is 
something that should be checked as part of validating the
R-cookie in the response. there should be enough information 
there for the R-node to work out what stack-proposal it would
have made (since this is supposed to be a matter of static
policy, and not dependent on the Query); if the confirm is
not valid, it can be rejected. (there is an 'invalid cookie'
error.)

- the point on timer setting is valid; certainly you should not
wait to the last millisecond before the Hello is sent. we had a
similar discussion on the routing state timer (also signalled
in the NLI, btw...) and the refresh operation. should this 
discussion be in the spec or in a (hypothetical) implementors'
guide, however? 

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 25 October 2005 14:29
> To: Thomas Herzog
> Cc: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] GIST Confirm contains no stack 
> configuration data, which holds MA_HOLD_TIME
> 
> 
> Hi Thomas,
> 
> > Section 4.4.1 states, "the GIST-confirm must contain 
> sufficient information to 
> > allow it to be processed identically to the original Query".
> 
> following from the problem below, the GIST-Confirm must 
> contain at least
> the MA-Hold-Time of the Q-Node. Sending the selected Q-Node Stack
> Proposal in the  GIST-Confirm may be one viable option though this is
> not really required since the MA was setup by the Q-Node already.
> 
> A further clarification may be required for the case when a Q-Node
> sets up an MA that differs from the R-Node Stack Proposal, e.g.
> the latter was TLS/TCP and TLS/SCTP :-), but the Q-Node setup a
> normal TCP connection w/o TLS (to which the R-Node listens, too, for
> connections of other peers). In this case the R-Node should check
> that the Q-Node used an MA that is not allowed by the R-Node Stack
> Proposal.
> 
> > However, a GIST-Confirm does NOT contain a stack 
> configuration data object (it 
> > is furthermore said, that even the stack proposal object it 
> carries is a 
> > mirror of the one it received in the response).
> > 
> > When the Querier Node wants to set up a C-Mode Message 
> Association, it will 
> > send the Confirm via the newly created C-Mode connection.
> > 
> > The Responder now must install the MA_HOLD_TIME of the 
> Querier, so its MA 
> > State Machine can set the SendHello timer accordingly (GIST 
> Hellos are sent 
> > from either direction to hold the MA open).
> 
> There should be another clarification in the draft.
> When should a node send these GIST-MA-Hellos exactly? It is only
> specified that
> a node MUST not tear down state for the period of MA-Hold-Time if no
> GIST message was seen over the MA. But I guess that setting the timer
> near MA-Hold-Time may be to fragile and a static setting may possibly
> cause undesired synchronization effects? Should the Hello send in the
> interval somewhere between 0.7 and 0.95 * MA-Hold-Time to avoid
> a tear down? Or should one set the NoActivity to MA-Hold-Time * 1.5?
> While it is ok to leave some implementation freedom I guess 
> that sending
> a GIST-MA-Hello exactly every MA-Hold-Time msec will not work for all
> implementations and scenarios.
> 
> > Unfortunately, in the late state installation case, it has 
> no access to the 
> > Querier's MA_HOLD_TIME, as this would be carried in the 
> stack configuration 
> > object, which is not included. (and even if it would be 
> included, it should 
> > be the mirrored one from the Response, fitting to the stack 
> proposal 
> > object...)
> 
> > So in my eyes, with the current draft, there is no 
> possibility to set up a 
> > Message Association in Late State Installation case!
> 
> I assume you're correct here. Other experiences?
> 
> Regards,
>  Roland
> 

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

---

From: Thomas Herzog <[email-masked]>
Date: Tue, 25 Oct 2005 16:46:40 +0200

> of purpose here). i will add a new issue for this.

Hm, but we should be aware that the NLI still has no "optional" fields at all, 
including an optional field would introduce also a flag to signal this.

This solution seems however really cute, as the NLI is supposed to be used as 
key identifying a MA, so it would also imply that every MA has its 
MA_HOLD_TIME in its NLI available, so also no additional data data structure 
is needed for saving it.

> not valid, it can be rejected. (there is an 'invalid cookie'

Yes, sounds good, a Responder Node would simply pull its ability data and 
check if the given R-Node stack proposal object in the confirm fits.

This would also allow to specify specific nodes (maybe on IP ranges) to which 
only secure connections may be made. So the Responder would check all this on 
Confirm reception.

But as I have read, it is also stated, that the contents of a Response shall 
not be dependent on the Query, but this would outrule the possibility of 
granting special connection possibilities to specific nodes?

A R-Node thus can only give its complete set of possible connections to a 
node, maybe this is not as flexible as one may want (the above possibility 
would be outruled)?

Cheers, Thomas

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Oct 2005 17:25:50 +0200

Hi Robert,

thanks for the fast response. My comments inline.

> and the stack-proposal is for the 'wrong' node anyway. this is

Agreed.

> of purpose here). i will add a new issue for this.

Good.

> not valid, it can be rejected. (there is an 'invalid cookie'

Hmm, then I don't see any reason why the R-Node Stack Proposal
should be repeated by the Q-Node anyway. A man in the middle
attacker may remove some protocols in the R-Node's stack proposal
within the GIST-Response, but he may also re-insert the original
stack proposal in the GIST-Confirm.
IMHO the R-Node must check anyway whether the established MA fits
to its own Stack proposal but if this is done according to the
own static list anyway, then the repetition of the R-Node's
Stack Proposal in the GIST-Confirm is superfluous anyway.
I think it is more interesting to be able to detect the
selection of a weak protocol. For instance, if both nodes offer
TLS/TCP and TCP but only TCP is selected that should make
the R-Node suspicious. However, according to the policy TCP
is acceptable anyway. So I don't see a reason to repeat
the R-Node's Stack Proposal. Maybe someone else could elaborate
what "certain bidding down attacks" means. Currently I don't
see any real value in it.

> discussion be in the spec or in a (hypothetical) implementors'

Hmm, I think that in this case the interoperability is affected.
So IMHO it should go into the spec itself.

Regards,
 Roland

---

From: Thomas Herzog <[email-masked]>
Date: Tue, 25 Oct 2005 17:37:47 +0200

Hi, Roland,

exactly, what I meant, too.

> see any real value in it.

To my understanding, even this case (selection of a weak protocol) is not 
really useful.

As the Message Transfer security is set by the NSLP which called SendMessage 
with "transfer-attributes=secure/reliable", it is also possible that the NSLP 
would NOT have required security (e.g. set only "reliable").

In this case, both nodes still send their full set of proposals, but the 
Q-Node is then free to use a "weak" connection.

(The Q-Node would include it's full ability set, because it could be that the 
R-Node local policy would require secure connections)

So selecting a "weak" Profile in case both nodes can support more secure ones 
can't be an error according to the spec.

Cheers, Thomas

---

From: Roland Bless <[email-masked]>
Date: Wed, 26 Oct 2005 18:00:24 +0200

Hi Robert,
>>of purpose here). i will add a new issue for this.

After some discussion with Thomas, we concluded that
it would possibly be a cleaner approach to send a
Q-Node Stack-Configuration Data in the GIST-confirm back,
essentially only containing one MA-Hold-Time, i.e. HL-Count=0
since the MA was setup already anyway.

Cheers,
 Roland