Subject: [Nsis-imp] some clarification questions regarding GIMPS

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Apr 2005 11:43:39 +0200

Dear all

We at the moment implementing the GIMPS protocol and we find that there are some issues
that would need some clarification, etc.

These issues are:

1- For the implementation of the discovery mechanism,it is important to know 
if a procedure has to be implemented to check whether the sender of the 
Query cookie is also the sender of the confirm cookie.

2- The value of the D-flag that corresponds to the upstream and 
downstream has to be specified.

3- The function of the source prefix and destination prefix of the 
MRI object has to be defined.

4- In our implementation we are only using IP-Ver 4. Therefore it might be 
useful to know if the entire 32 bit word for the Flow Label parameter in the 
MRI object must be ignored or set to zero (empty object).

Could you clarify the above?

Best regards,
Georgios
_______________________________________________
NSIS-imp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis-imp

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 26 Apr 2005 11:56:41 +0100

and a brief followup on the cookie front:

for *interoperability* the only thing that is required is to
copy the cookies correctly between Q/R/C messages. so, for
testing, that is the only thing that will get exercised.

the *generation and validation* you do is up to the implementation 
and not visible externally (you might just generate a random
number and not validate anything). we will give informative
examples in the spec of how to do a good job, however. but 
in any case we will ensure that they don't violate the basic
design goals (e.g. stateless handling of an initial query.)

r.

> -----Original Message-----
> From: Hancock, Robert 
> Sent: 26 April 2005 11:48
> To: Georgios Karagiannis; [email-masked]
> Subject: RE: [Nsis-imp] some clarification questions regarding GIMPS
> 
> 
> hi georgios,
> 
> thanks for the questions! see in line...
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[email-masked]] 
> > Sent: 26 April 2005 10:44
> > To: [email-masked]
> > Subject: [Nsis-imp] some clarification questions regarding GIMPS
> > 
> > 
> > Dear all
> > 
> this is a hard question. the ideal answer is 'yes' but, given
> that the purpose of the 3 way handshake is supposed to allow 
> the responding node to forget the query contents and work only
> with the confirm, it is not clear to me at the moment that it
> is possible in general, unless the responder cookie is designed
> to refer to information that will be repeated in the confirm.
> (we have started this discussion at 
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17)
> 
> we need to do more work on this, and i have text lying around,
> but still need to make it comprehensible (and plausible).
> 
> > 
> do you just mean 'is 1 up and 0 down or the other way round'?
> or something more subtle?
> 
> > 
> this is to allow wildcarding on address fields. the signalling message
> delivery uses the actual addresses, but the MRI is interpreted as
> referring to the whole subnet (e.g. might be used by an NSLP as a
> wildcard in a traffic classifier). GIMPS should reject 'too broad'
> wildcards (in a manner to be defined in the next version of the
> draft).
> 
> > 
> wrong on both counts (see
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue34
> which we wrote during the interoperability testing
> in minneapolis). the short answer is:
> if the flag for a field in set in the first word, the field must
> be present and interpreted as significant
> otherwise, the field must not be present at all.
> 
> (this is supposed to be implied by the ':' symbols in the box
> notation indicating 'optional fields' but I accept it is a bit
> hard to spot and the next version will be more explicit.)
> 
> at the moment my expectation is not to try to pin down exactly
> which version/flag combinations must be supported, but to 
> rely on common sense (e.g. people won't generate MRIs with v=4
> and F set) and defining a general purpose ICMP-like 'parameter 
> problem' message to allow people to report that they don't like
> particular settings. i'd appreciate input on that, however.
> 
> hope this helps,
> 
> r.
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 29 Apr 2005 09:49:07 +0100

hi georgios,

answers below:

> Sent: 28 April 2005 09:29
> To: Hancock, Robert; [email-masked]
> Subject: Re: [Nsis-imp] some clarification questions regarding GIMPS
> 
> 
> Hi Robert 
> 
> Thank you very much!
> Regarding points 2 and 3., see below:
> 
> What I mean, is:
>  'is 1 up and 0 down or the other way round'?

the D=direction flag is:
if clear: in the same direction as the flow
if set: in the opposite direction to the flow

for example, a Query would normally have D=0 and the 
Response D=1.

i've given myself an editorial issue to make this clearer.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue42

> Could you please give an example?

this is a more interesting question, which will send me into 
discursive mode briefly:

the addresses in the MRI have a dual significance:
- they tell GIMPS how to encapsulate the Q/R/C messages (i.e. what
source and destination addresses to use for them) and hence 
implicitly define the path;
- they form part of the definition of which packets the signalling
is about (i.e. is used as part of the packet classifier).

For the second, sometimes a wildcard is appropriate (see e.g.
draft-bajko-nsis-FW-reqs-00.txt and the various protocol
specs). An example would be a IPv6 'leaf network' with a /64
address range allocated (like a cellular host) which wanted to
signal something about all its addresses (e.g. it might be using
privacy addresses) without carrying out multiple signalling
exchanges. For this reason, you can apply a prefix length to the
addresses to implement this wildcarding.

To take a concrete example of a single GIMPS data message
  MRI(IPversion = 4,
	Flow source = 123.231.112.45,
	Flow destination = 56.78.90.12,
	Source prefix length = 24,
	Destination prefix length = 32,
	Direction = 0 [downstream])

The message will go along the path between 123.231.112.45 and
56.78.90.12 (and a Query message would use precisely those addresses
in its IP header), but will refer to packets from anywhere in 
123.231.112.0/24 to 56.78.90.12.

It's possible for wildcarding to be too wild (e.g. setting a
prefix length to 0). If the prefix length is too short for the
path (i.e. it includes addresses for which the packets would
go along different paths), it's up to GIMPS to reject the
message. I am working on the error messages at the moment ;-)

Hope this helps,

Robert H.

> 
> Best Regards,
> Georgios
> 
> ----- Original Message ----- 
> From: "Hancock, Robert" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, April 26, 2005 12:47 PM