Re: Invalid IP in INIT/INITCAK message

[Randy Stewart <[e-mail]>]

Dan:

SOme comments in-line..


On Sep 16, 2010, at 1:11 PM, Dan Wing wrote:

>> -----Original Message-----
>> From: Michael Tüxen [mailto:[e-mail]]
>> Sent: Thursday, September 16, 2010 12:58 PM
>> To: Dan Wing
>> Cc: 'Randy Stewart'; 'Chris Benson'; 'tsvwg'
>> Subject: Re: Invalid IP in INIT/INITCAK message
>>
>> 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.
>
> But how do we prevent the association from being ABORTed,
> as described in
> http://tools.ietf.org/html/draft-stewart-tsvwg-sctp- 
> ipv4-00#section-3.2
>
> Seems in addition to what is described in that I-D, some ABORTs will
> need to be ignored.

Well actually if the client outside follows the scoping draft as Michael
said you would NOT list the 10. network and thus no abort would be
generated.

And if you want to use the 10. network in the association then you would
need to have the client send the INIT to the 10. network to begin with.

This is the only way that the server would then know its safe to list
the 10. network and that the clients 10. network is reachable and the  
same
one as the servers...

The heart of the idea is to only list address that are in scope of
the association. If an address is not in scope then the client does
not list it... thus no aborts...

This is the same sort of thing that we do with link-local address in  
V6... the
only way you can add one to an association is NOT list it and send to  
your peer
(somehow the client must know which interface... KAME-BSD did this  
interface
index thing in the destination address)... and that way when you  
received the
packet you would include the link local address and be able to snatch  
in what
the actual input interface was....

You have the same problem there... since a link local on one network  
may be on another
at a different host...

If you follow the rules of those two drafts (which do need to be  
merged and resurrected) then
you would never have any stray aborts floating around..

R


>
>
>>> 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.
>
> The client cannot always know the server also has a private address.
> If it could, all of the server's addresses would be in DNS and
> we wouldn't need to have the addresses in INIT / INIT-ACK.
>
> -d
>
>> 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]
>>>>
>>>>
>>>
>>>
>>>
>
>

-----
Randall Stewart
[e-mail]