Subject: Re: [Tsvwg] Review comments for SCTP MIB

From: Maria-Carmen Belinchon <[email-masked]>
Date: Mon, 02 Sep 2002 15:27:06 +0200

Hi,

Here's included only the Shawn's comments in which we have some remarks:

> >3) Can an Association be in the sctpAssocTable before it is fully formed?
> >   In particular can sctpAssoc{Local Rem}Port be zero if the association
> >   isn't completely formed yet?

The entry in the sctpAssocTable exists even when the association is not fully
formed. During cookie-wait and cookie echoed states, entries have been created and
the association establishment is in progress.
Ports are known at the time the association row is created, so the value can never
be zero. That's the reason because the value zero was not allowed ->
InetPortNumber (1..65535)

> >5) The text for sctpAssoc{Local Rem}AddressType mentions the use of
> >    unknown (0) when the associated address (sctpAssoc{Local Rem}Address)
> >    is empty or unkown however the addresses are never allowed to be
> >    empty as they have a syntax with size (1..36).  Also note that the
> >    text for the address objects also seems to allow for a zero length
> >    value.  Either the text or the syntax should be corrected.

Yes, it should be corrected. This is the way entries are created:

The association row is created when the association is trying to be initiated
(originating side sending the INIT message or peer sending INIT ACK).

When the originating side sends INIT message, he creates the association row in
the sctpAssocTable, and the remote IP address is the one he tries to connect to.
At this point, sctpAssocRemAddressType=1, 2, ... (depending of the IP address
type, never DNS type) and sctpAssocRemAddress=<IPaddress>.
Also, sctpAssocLocalAddressType=1, 2, ... (depending of the IP address type, never
DNS type) and sctpAssocLocalAddress=<IPaddress>, where it's possible to have more
than one entry in the Local Table if the local endpoint is multihoming.
At this point, all lookup tables are created.

When the remote endpoint receives the INIT and decides to accept the association,
he will create his row in the sctpAssocTable with as many rows in the Local and
Remote tables as local and remote IP address he's aware of. All the
sctpAssocRemAddressType and sctpAssocLocalAddress will have values different from
zero.
At this point, all lookup tables are created.

When the originating side receives the INIT ACK message, he completes the rows in
the sctpAssocRemAddressTable and creates the lookup tables concerning the remote
IP addresses.

All this leads to think that sctpAssocRemAddressType can never be zero, so the
text should be changed. The initial idea was to leave open the option that the
implementor doesn't fill in the sctpAssocLocalAddress until INIT ACK has been
received in order to have all the possible remote IP addresses at the same time.
In this case, when sending the INIT the originating side,
sctpAssocLocalAddressType=0 to point that sctpAssocLocalAddress has no a valid
value, and sctpAssocLocalAddress=0 since it cannot be empty due to the size
restriction. But maybe it's better to force to create the remote rows regarding
the known remote IP address at the INIT sending, and add more rows if at reception
of INIT ACK it's discovered that the peer is multihoming.

> >7) What should happen with the sctpLookupRemHostNameEntry if the
> >   sctpAssocRemHostName doesn't yet exist?

The sctpLookupRemHostName table will be created after a row in the sctpAssocTable
has been created and ONLY if the sctpAssocRemHostName has a value different from
NULL (i.e., the remote host name is known). So the premise you mention will never
happen.

> >The use of optional tables in MIBs is somewhat of a odd issue.  While
> >it is nice to avoid adding the overhead of these tables to systems that
> >don't need them if they are optional no management station can actually
> >expect to use them.  I'd like to understand how you think they might be
> >used - for example when an entity would implement and populate them and
> >when a management station would decide to try and use them.  (Note: at
> >this point I am not suggesting you change anything, I'm just trying to
> >understand your model of the world.)

The optional tables are the lookup tables, and thay are optional because they're
just a quicker way of getting information based on a key object.Without them, you
can get the same information, but in an odder way. I don't see the reason of
having them as mandatory since not all systems could want to use them, but I see
them important to be present in the MIB since they allow to be used by those
systems who requires to (also it was requested to be in the MIB in the San Diego
meeting).

> >You should also be clear what happens in a lookup table if the field
> >used for indexing that table is not yet valid in the main table.  You
> >might need to add some text in both this section and in the MIB text.

All Lookup table indexes already exist in the main table.

> >Will the timestamp in the reverse lookup tables be different than the
> >timestamp in the association table?

Yes. Timestamp means the time this specific row has been created in this specific
table.

br,
MCarmen

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 17 Sep 2002 07:04:11 -0500

Maria:

A very late comment since I am so far behind in my email catchup ..
sigh..

> At this point, all lookup tables are created.

Why would you create anything at this stage if one was the receiver of
the INIT? The whole purpose of the 4-way handshake is to NOT create
any state. You really do not know if the INIT that was sent to
you was spoofed or not. Would you not take this step when you
receive the COOKIE?

> of INIT ACK it's discovered that the peer is multihoming.

I think the above logic still holds.. its just that the receiver of
the INIT will not create anything in the MIB until AFTER it receives the
COOKIE and validates its signature...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg