Subject: Re: [NSIS] GIST issue on MA-Hold-Time

From: Roland Bless <[email-masked]>
Date: Mon, 06 Nov 2006 08:45:52 +0100

Hi Robert,

Hancock, Robert wrote:
> I am not sure how to do this in an interoperable way without 
> quite a bit of extra complexity (some more message rounds). I'd
> prefer just to emphasise that it's silly to use small values.
> Any text suggestions?

So you suppose that rejecting too small values would not
be a good choice? For instance, if a node sends an MA-Hold-Time
of 20 (ms), this node will usually get the traffic, so it
cannot be misused as an attack. However, if we allow to reject an
MA-Hold-Time value, we probably must add a mechanism that
doubles the MA-Hold-Time. Did you mean this with "some more message
rounds"? I'm not convinced that it makes sense.

>> * The MA-Hold-Time must be repeated in the first Confirm message
>>   due to the need for having this value available even if late
>>   state installation is used.
>>   => What should be done if the MA-Hold-Time is missing?
>>   Sending back an Object-Type error with mandatory object missing is
>>   probably the right thing to do.
> 
> Done.
> 
>>   Furthermore, the specification in 5.1 of the Confirm message
>>   is confusing in this respect and should be clarified.
>>        Confirm = Common-Header
>>                  Message-Routing-Information
>>                  Session-Identification
>>                  Network-Layer-Information
>>                  [ Responder-Cookie
>>                   [ Stack-Proposal
>>                      [ Stack-Configuration-Data ] ] ]
>>                  [ NSLP-Data ]
>>   While the example in fig.4 sheds more lighty on how it is
>>   intended, one would think that Stack-Proposal _and_ SCD
>>   of the Responder are repeated in the Confirm (so I guess
>>   nesting with brackets must be fixed). Therefore,
>>   clarification is needed that only the R-Node SP is repeated
>>   (w/o R-Node SCD)
>>   and the Q-Node SCD with MA-Hold-Time is mandatory in the
>>   very first Confirm. 
> 
> I think that the ABNF is correct here; the real problem is that
> ABNF is not a good syntax for handling 'conditionally mandatory'
> information elements. More discussion is in the issue tracker.
> Also, I don't really want to qualify which SP is included 
> (since this makes the ABNF harder to validate). Hopefully the
> new text before the ABNF in 5.1 makes this clearer.

Ok.

Regards,
 Roland

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

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 6 Nov 2006 02:12:54 -0800

hi roland,

> be a good choice? 

I did think of allowing a node (MAY) to send back Object Value Error
and drop the MA if the Hold-Time is 'too small'. I suppose that this
would then put the obligation on the initiator to have another go
with a sensible value, without putting a lot more complexity in the
protocol spec. I'd still like to put a bound on when this was
allowed - say for times < 1 second?

> For instance, if a node sends an 
> MA-Hold-Time of 20 (ms), this node will usually get the 
> traffic, so it cannot be misused as an attack. However, if we 
> allow to reject an MA-Hold-Time value, we probably must add a 
> mechanism that doubles the MA-Hold-Time. Did you mean this 
> with "some more message rounds"? I'm not convinced that it 
> makes sense.
> 
> > I think that the ABNF is correct here; the real problem is 
> that ABNF 
> > is not a good syntax for handling 'conditionally mandatory' 
> > information elements. More discussion is in the issue 
> tracker. Also, I 
> > don't really want to qualify which SP is included (since this makes 
> > the ABNF harder to validate). Hopefully the new text before 
> the ABNF 
> > in 5.1 makes this clearer.
> 
> Ok.

cool.

cheers,

r.