Subject: RE: [Tsvwg] INIT/INIT-ACK address list too long

From: Tuexen Michael <[email-masked]>
Date: Wed, 15 May 2002 13:24:46 +0200

Dear Manuel,

what about the error cause:

Out of Resource

It is defined in 3.3.10.4 of RFC 2960.

That seems be be a reasonable way to tell your peer
to use less addresses.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Manuel Urue> ña Pascual [SMTP:[email-masked]]
> Sent:	Wednesday, May 15, 2002 1:19 PM
> To:	[email-masked]
> Subject:	[Tsvwg] INIT/INIT-ACK address list too long
> 
> Hello,
> 
> Maybe this was previously discussed but I haven't found anything,
> (sigtran mailing list archive before 2001 seems to be empty).
> 
> My question is:
> 
> ¿What happens when an endpoint has an limited TCB size and cannot store
> whole INIT/INIT-ACK chunk address list?
> 
> An scenario:
> 
> Alice has five IPs: IP1 IP2 IP3 IP4 IP5 and sends an INIT to Bob listing
> all of them, but Bob just stores IP1 and IP2 in its COOKIE TCB (maybe
> Bob is a PDA with little memory).
> 
> Alice doesn't know, as COOKIE is opaque, that IP3, IP4 and IP5 are
> invalid for this association so it may send a packet from one of these
> and Bob will handle it as a OOTB and send back an ABORT killing current
> association.
> 
> So, ¿how can Bob tell Alice that IP3 IP4 and IP5 and invalid addresses
> for that association? 
> 
> Current ERROR causes related to parameters are:
> Unresolvable Address (5)
> Invalid Mandatory Parameter (6)
> Unrecognized Parameters (8)
> 
> None seems to fit. ¿maybe 5?
> 
> Best regards,
> --Manuel
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 15 May 2002 07:17:34 -0500

Michael:

That is exactly what we had in mind... if you don't
have enough resources (in this case TCB space for all
the IP addresses) you send this message with your abort...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 15 May 2002 17:14:02 +0200

Randall, Michael:

Out of Resource error cause cannot tell which parameters are affected as
it is a global error. So if you receive an Abort with an Out of resource
Error chunk you can't know if the other endpoint cannot accept more
associations and you must stop further attempts for a while or keep
sending INITs with a shorter address list.

In this scenario, receiver actually has enough resources, but wants to
limit length of TCB entries. RFC 2960 does not limit the size of address
list so always accept all addresses migth lead to a DoS attack (an INIT
packet may be up to 1500 octets long), not very dangerous but it may be
nice to handle it. :)

Best regards,
--Manuel

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 15 May 2002 19:40:14 +0200

Hi,

I absolutely agree to aggregate errors, but IMHO errors within
association establishment should be treated carefully as they may affect
interoperation between implementations.

Address lists are important info not ACK'd by any means, and that may be
a problem.

Instead of creating a new error cause, which doesn't scale very well
:-). It may be an option to extend the semantic of Unresolvable Address
(5) error cause, which is already related to address list, to handle
also this error.

Regards,
--Manuel

> Hi, Manuel,
> 
> I agree that finer error reporting can help debugging. But, with various
> ways of implementing the stack and different use scenarios, there are a
> great number of different reasons an error can occur. It is simply
> impractical to create an error cause for each one of them.
> 
> -Qiaobing
> 
> Manuel Urueña Pascual wrote:
> > 
> > Randall, Michael:
> >

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 15 May 2002 11:10:13 -0500

Hi, Manuel,

-Qiaobing