Re: Invalid IP in INIT/INITCAK message

[Michael Tüxen <[e-mail]>]

On Sep 16, 2010, at 9:26 PM, Dan Wing wrote:

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Randy Stewart
>> Sent: Wednesday, September 15, 2010 1:58 PM
>> To: Chris Benson
>> Cc: tsvwg
>> Subject: Re: Invalid IP in INIT/INITCAK message
>> 
>> Chris:
>> 
>> Even besides the point you make is another issue in several
>> drafts that have been lost to time (and probably should be
>> resurrected).
>> 
>> It is completely possible for a peer to list an address that it
>> really has but is not really valid for you. I.e. address scoping.
>> 
>> If the peer incorrectly scopes its address and for example
>> sends a private address "10.1.1.1" with its init..
> 
> Let's say the SCTP server has two inerfaces -- one public-facing
> with a public IPv4 address, and another is 10.1.1.254.
> 
> How is the incoming SCTP INIT to the public IPv4 address, containing
> 10.1.1.1 in the INIT, supposed to be handled?  
Hi Dan,

we need to bring back the address scoping IDs... There was actually
one for IPv4 see
http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ipv4-00
and one for IPv6
http://tools.ietf.org/html/draft-stewart-tsvwg-sctpipv6-00

They need to be combined based on the so called level
from the first ID...

The client should not list the private address in the INIT,
when it is sent to a public address.
This is described by the second bullet of section 3.3 of the
above ID. The FreeBSD implementation would not list the address.


> 
> Seems the SCTP client and server should try to use 10.1.1.1 and 
> 10.1.1.254 (when they are on the same network) but it's also 
> important to not abort their association if they aren't on 
> the same network (and there is another SCTP host on the 
> local network, listening on the same port).
I think they should NOT list the addresses. If they want to use it,
the client should send the INIT to the private address listing
the global one.

Best regards
Michael
> 
>> In such a case you probably don't want to destroy the assoc.. but
>> instead
>> silently discard the address.
>> 
>> V6 Link local address are in this same category.. If the source address
>> is a link local.. fine you can use it since you can determine which
>> link
>> it goes with.. But if the link local is listed... then the address,
>> though
>> valid for the sender is un-useable by the receiver since the receiver
>> will
>> not know which link it goes with.
> 
> Agreed that is a problem for link local (fe80::/64).
> 
> What of ULA (fc00::/7), which seem they could suffer the same scoping
> problem as RFC1918 addresses -- namely, can't tell if the peer is
> in the same scoped network or not.
> 
> -d
> 
> 
>> R
>> 
>> On Sep 14, 2010, at 11:48 AM, Chris Benson wrote:
>> 
>>> Dear Padmalochan,
>>> 
>>> Before considering an appropriate ABORT error code, I am
>>> not convinced that including [additional] invalid IPv4
>>> addresses (such as 0.0.0.0 or 255.255.255.255) should
>>> abort the establishment of the association.  I'll assume
>>> that there is a valid address somewhere, because the
>>> chunk got here!
>>> 
>>> I'll pose this preliminary question:
>>> 
>>> (Q1) If an INIT or INIT ACK message contains a well-formed but
>>> numerically unusable IPv4 address, should the association setup
>>> be aborted?
>>> 
>>> The RFC mentions an extreme case of an INIT ACK chunk containing
>>> 1,000 IPv4 addresses.  It seems harsh (to me) to reject the
>>> whole association if one of these addresses is not usable.
>>> 
>>> There are "clues" in the RFC that one might proceed anyway
>>> (assuming at least one usable address).  This is mentioned
>>> several times, including here:
>>> 
>>> RFC 4960 Section 5.1.2, 2nd IMPLEMENTATION NOTE, page 60.
>>>  IMPLEMENTATION NOTE: If an SCTP endpoint that only supports
>>>  either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an
>>>  INIT or INIT ACK chunk from its peer, it MUST use all the
>>>  addresses belonging to the supported address family.  The
>>>  other addresses MAY be ignored.  The endpoint SHOULD NOT
>>>  respond with any kind of error indication.
>>> 
>>> On your actual question, it seems to me that "Unresolvable
>>> Address" is intended for an incoming request to use an Address
>>> Type that is not supported ("unwilling or incapable") by the
>>> receiver. So you would use this error code if you didn't
>>> support IPv4 addresses at all, for example.
>>> 
>>> I don't see a more appropriate error code, though. Perhaps
>>> this is because the answer to my (Q1) above is "no".
>>> 
>>> Various IPv4 multicast addresses (224.0.0.0 - 239.255.255.255)
>>> including link local addresses, similarly don't seem appropriate
>>> for SCTP.  I would be inclined not to police every address at
>>> the expense of the association.  I'd just discover during the
>>> association that it isn't "reachable".
>>> 
>>> With thanks, from Chris Benson.
>>> 
>>> On Wed, 8 Sep 2010, Padmalochan Moharana wrote:
>>> 
>>>>> Date: Wed, 8 Sep 2010 12:55:06 +0530
>>>>> From: Padmalochan Moharana <[e-mail]>
>>>>> To: tsvwg <[e-mail]>
>>>>> Subject: Invalid IP in INIT/INITCAK message
>>>>> 
>>>>> Hi All,
>>>>> What should be the behavior of the SCTP endpoint on receive INIT/
>>>>> INIT
>>>>> ACK message with invalid IP (0.0.0.0 or 255.255.255.255)?
>>>>> Should endpoint discard the received INIT/INITACK message and
>>>>> response
>>>>> ABORT with error cause Unresolvable Address?
>>>>> 
>>>>> Br,
>>>>> Padmalochan
>>>>> 
>>> 
>> 
>> -----
>> Randall Stewart
>> [e-mail]
>> 
>> 
> 
> 
>