Subject: [Tsvwg] ICMP protocol unreachable

From: vijeyk <[email-masked]>
Date: Thu, 05 Oct 2006 17:48:29 +0530

Hi,
      I needed some clarification  on the ICMP protocol unreachable issue,
      Consider  a  scenario  where the host is configured in a way that  my
      destination  is multi homed , say  ip -a ,ip-b,ip-c with ip -a  
taken as the primary
      address, with some kind of a  firewall  for  ip-b and  ip-c.

      Now  if  i send  a SCTP packet to ip-b and ip -c  and get  
ICMP(protocol unreachable),
      section 2.37 of RFC 4460 (appendix c),says
      " <>        If the ICMP code is a "Unrecognized next header type 
encountered" or a "Protocol Unreachable", an implementation

                MUST treat this message as an abort with the T bit set 
if it  does not contain an INIT chunk.  If it does contain an INIT

                chunk and the association is in COOKIE-WAIT state, 
handle the    ICMP message like an ABORT."

      When  it  says  ABORT , does it mean  that  i  have  to  bring 
down the association  bcoz once i do that ,i can henceforth only
      send packets to the primary address (ip -a)? Dont  u think this is 
a disadvantage bcoz the firewall might be reconfigured at a
      later point in time where the i might be able to send  packets to 
the destination which was unreachable earlier , but now i have
      already aborted the association and am unable to do the 
same.........???????ur comments plz...........

---

From: Randall Stewart <[email-masked]>
Date: Thu, 05 Oct 2006 15:56:32 -0400

vijeyk wrote:
>                MUST treat this message as an abort with the T bit set if 
> it  does not contain an INIT chunk.  If it does contain an INIT
> 
>                chunk and the association is in COOKIE-WAIT state, handle 
> the    ICMP message like an ABORT."
> 
> 
>      When  it  says  ABORT , does it mean  that  i  have  to  bring down 
> the association  bcoz once i do that ,i can henceforth only
Yes it means the association must come down.. if you get
an ICMP Protocol unreachable the "HOST" does NOT understand
SCTP.

Now if a firewall is sending this, its broken (see the previous
LONG email thread on this)..

A F/W SHOULD be silently discarding packets if it does NOT
want SCTP to go across it. Note, another valid question is why
does it not want SCTP to go across it if it is being used
in its network in a multi-homed scenario... either
a) The admin does not know about it
or
b) The admin is not planning things very well.

I have not had any trouble with my F/W and SCTP... it
is configured to let it through :-)

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Oct 2006 18:45:52 -0700

> A F/W SHOULD be silently discarding packets if it 
> does NOT want SCTP to go across it. 

In RFC1812, section 5.2.7.1, "Destination Unreachable", an ICMP code was
defined that seems well-suited for this purpose:

   > The following additional codes are hereby defined:
   >
   > 13 = Communication Administratively Prohibited - 
   >      generated if a router cannot forward a 
   >      packet due to administrative filtering;

Can this not be used?

-d

---

From: Stephane Chazelas <[email-masked]>
Date: Tue, 10 Oct 2006 08:36:53 +0100

>    >      packet due to administrative filtering;
[...]

That's at network level, not transport. That says that no
traffic should go there, not that not this kind of traffic
should go there.

(I think)

regards.
Stephane

---

From: Stephane Chazelas <[email-masked]>
Date: Tue, 10 Oct 2006 09:20:50 +0100

[...]

Though now that I read it again, I wonder what made me think
that in the first place. It's true that reading RFC 1812, you
could say that it'd be a sensible thing to use.

However, looking at Linux code for instance, it seems it uses it
for "route prohibit" things.

regards,
Stephane

---

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Oct 2006 09:52:01 +0200

> traffic should go there, not that not this kind of traffic

As an individual participant, I'm with Dan here - I think  
"communication administratively prohibited" would be fine to use.  
("Protocol unreachable" may also be an option, but doesn't quite have  
the right semantics.)

Dan, do any BEHAVE drafts say anything on this?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Oct 2006 11:37:10 -0700

> >>>      packet due to administrative filtering;
...
> ("Protocol unreachable" may also be an option, but doesn't 
> quite have the right semantics.)
> 

The only BEHAVE draft that mentions this is
draft-ietf-behave-nat-icmp-01.txt, which says:

    >
    >  When the first packet of an outbound flow is prohibited
    >  by a NAT device due to resource constraints or
    >  administration considerations, the NAT device SHOULD
    >  send ICMP destination unreachable message.  Section
    >  5.2.7.1 of [RFC1812] recommends routers to use ICMP
    >  code 13 (Communication administratively prohibited)
    >  when they administratively filter packets.  As such, a
    >  NAT device MUST use ICMP code 13 when generating an
    >  ICMP error message.
    >
    >  REQ-8: When a NAT device is unable to establish a NAT
    >  Session for a new flow due to resource constraints or
    >  administrative restrictions, the NAT device SHOULD send
    >  an ICMP destination unreachable message, with a code of
    >  13 (Communication administratively prohibited) to the
    >  sender, and drop the original packet.
    >

The BEHAVE WG doesn't have an "IP behavior" document that describes what a
NAT should do when it receives a packet for a protocol it doesn't
understand.  As it is, the above requirement teeters on the edge of defining
a NAT's behavior when receiving an IP packet.

-d

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Oct 2006 13:45:04 -0300

At 16:56 05/10/2006, Randall Stewart wrote:

>>      When  it  says  ABORT , does it 
>> mean  that  i  have  to  bring down the association  bcoz once i 
>> do that ,i can henceforth only
>>      send packets to the primary address (ip -a)? Dont  u think 
>> this is a disadvantage bcoz the firewall might be reconfigured at a
>>      later point in time where the i might be able to 
>> send  packets to the destination which was unreachable earlier , but now i have

What if it's just that the packet was misdelivered?

In the case of IPv6, there's no checksum at IP, so it's even more 
probable than for IPv4.

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Oct 2006 13:45:04 -0300

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 14 Oct 2006 10:29:48 +0200

Hi Fernando,

see my comments in-line.

Best regards
Michael

On Oct 13, 2006, at 6:45 PM, Fernando Gont wrote:

>>>      When  it  says  ABORT , does it mean  that  i  have  to   
>>> bring down the association  bcoz once i do that ,i can henceforth  
>>> only
>>>      later point in time where the i might be able to send   
>>> packets to the destination which was unreachable earlier , but  
>>> now i have
Then the V-Tag does match and the ICMP message is ignored.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Oct 2006 00:42:36 -0300

>Then the V-Tag does match and the ICMP message is ignored.

Why shouldn't it match?

The ICMP error message is elicited by a packet that you did sent. 
It's just that it gets (mistakenly) delivered to a host that does not 
implement SCTP.

Kindest regards,

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 15 Oct 2006 10:23:38 +0200

Hi Fernando,

I'm not sure about the scenario you are considering. I'm making the
one I'm thinking about explicit. You you are talking about a different
one, please describe it.

I'm sending an SCTP packet to a destination and somehow the destination
address gets modified and the packet is delivered to the host with
the modified IP-address.
If that host supports SCTP he will send an ABORT to me. I'll drop it
since it has not an IP-address / port number / V-Tag combination which
is valid, right.
If I get back an ICMP, it is also from the modified address and the
address/port/v-tag check will fail.

Best regards
Michael

On Oct 15, 2006, at 5:42 AM, Fernando Gont wrote:

> It's just that it gets (mistakenly) delivered to a host that does  
> not implement SCTP.
>
> Kindest regards,
>
> --
> Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Oct 2006 04:48:25 -0300

>address/port/v-tag check will fail.

I'm referring to this last case. However, either I'm missing 
something, or I don't agree with your analysis.

If the packet gets misdelivered to a system that does not support 
ICMP, then that host will send an ICMP "protocol unreachable" that 
will contain in its payload part of the packet that elicited the ICMP 
error message.

The only way in which you could "detect" that this message is being 
sent by some other system other than the other SCTP peer would be 
checking the source address of the ICMP error message. But I'm not 
sure you can enforce such a check. (Unless the current specs state 
that in order for ICMP messages to be considered valid they should 
come from one of the IP addresses that are part of the SCTP association).

Kindest regards,

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Oct 2006 08:15:54 +0200

Hi Fernando,

see my comments in-line.

Best regards
Michael

On Oct 16, 2006, at 9:48 AM, Fernando Gont wrote:

> will contain in its payload part of the packet that elicited the  
> ICMP error message.
This part contains the IP header (with the modified destination IP- 
address) and the SCTP common header.
> come from one of the IP addresses that are part of the SCTP  
It will use the ICMP payload.

 From RFC 4460:

    ICMP5) An implementation MUST use the payload of the ICMP message  
(V4
           or V6) to locate the association that sent the message that
           ICMP is responding to.  If the association cannot be  
found, an
           implementation SHOULD ignore the ICMP message.

    ICMP6) An implementation MUST validate that the Verification Tag
           contained in the ICMP message matches the verification tag of
           the peer.  If the Verification Tag is not 0 and does NOT
           match, discard the ICMP message.  If it is 0 and the ICMP
           message contains enough bytes to verify that the chunk  
type is
           an INIT chunk and that the initiate tag matches the tag of  
the
           peer, continue with ICMP7.  If the ICMP message is too short
           or the chunk type or the initiate tag does not match,  
silently
           discard the packet.

We do not look at the IP-header of the ICMP packet, but I think it is  
OK to just
use the ICMP payload.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 00:49:44 -0600

Michael,

The requirement to abort the association creates another attack.  Send
faked ICMP Protocol Unreachable to HOST A with its IP address and
Google's IP address and run up through the verification tags.

While your at it, INIT a whole bunch of vtags from HOST A that will be
good for cookie_life that can be skipped when running through the vtags
above.

Maybe there are better ways to do that: check for the verification HB
nonce in the ICMP packet (rearrange the HB none packet to plaignaling congestion in layer 2 switches.
> Wait...I see it at the end of 6.6 (layer 2 queues and operation
> logic).

I think it could be useful to mention this as one example of interaction
between L2 and upper layer mechanisms. I guess these need to be
evaluated on a case-by-case basis: 802.1au relates to congestion control
mechanisms, but not so much with the others (such as Path MTU discovery,
etc.).

Thanks, good comments.

- Pasi

--=-AE+lfOBzi9V7fdtc5deG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-AE+lfOBzi9V7fdtc5deG--

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 00:49:44 -0600

Michael,

Maybe there are better ways to do that: check for the verification HB
nonce in the ICMP packet (rearrange the HB none packet to place the
nonce right at the beginning of the packet); only abort if expecting a
responds to a nonce-HB and one has not been received; only abort for
non-verified addresses (verified addresses obviously support the
protocol and the ICMP must be spoofed).

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

ce the
nonce right at the beginning of the packet); only abort if expecting a
responds to a nonce-HB and one has not been received; only abort for
non-verified addresses (verified addresses obviously support the
protocol and the ICMP must be spoofed).

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 05:49:39 -0600

Randall,

I think that it might be an idea to change ICMP8 to read:

ICMP8) If the ICMP code is an "Unrecognized next header type
   encountered" or a "Protocol Unreachable", an implementation MUST
   treat this message as an abort with the T bits set if it was sent to
   an UNCONFIRMED address.  If the message contained in the ICMP payload
   was sent to a CONFIRMED address, an implementation MAY ignore the
   ICMP message.

Then, if the address is CONFIRMED, misbehaving firewalls cannot destroy
associations with other viable paths.  Also, spoofed ICMP messages
cannot take down an association except during the narrow window when
addresses are being confirmed.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Oct 2006 13:48:02 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> The requirement to abort the association creates another attack.  Send
I do not think so.
> Google's IP address and run up through the verification tags.
The attacker can do the same by faking ABORT messages.
> good for cookie_life that can be skipped when running through the  
Are you saying that Host A does change its state when sending the  
INIT-ACK
by "reserving" a V-Tag?
> protocol and the ICMP must be spoofed).
You only know that the SCTP common header is inside the ICMP payload.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Oct 2006 15:00:01 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> addresses are being confirmed.
I think the way to handle misbehaving firewalls is to fix the firewalls.
And there is no difference between spoofing ICMP messages and spoofing
SCTP messages with an ABORT chunk. Therefore I think ICMP8 should  
stay as
it is.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 07:07:15 -0600

Michael,

But there is no risk from CONFIRMED addresses and therefore
aborting the association cannot be required for messages
sent to them, and you cannot justify the MUST for them.  I
don't think the MUST can be justified for single-homed
associations either.

 a) there is no risk for sending messages to confirmed addresses.
 b) ignoring protocol unreachable would be realigned to that
    for TCP for confirmed addresses, increasing interoperability

Please make this an official Last Call issue.

--brian

Michael Tuexen wrote:                                              (Tue, 17 Oct 2006 15:00:01)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Oct 2006 21:48:04 +0200

Brian,

see my comments in-line.

Best regards
Michael

> don't think the MUST can be justified for single-homed
For me there is no difference in getting an ICMP(protocol unreachable)
and an ABORT. So they should be handled the same way. Think about
an application using a user land implementation. It the application
crashes you get back an ICMP(protocol unreachable) which tells
you the same as an SCTP kernel implementation when an application
has crashed, which would most likely be an ABORT.
>  a) there is no risk for sending messages to confirmed addresses.
See above.
>     for TCP for confirmed addresses, increasing interoperability
I do not know what the concept of confirmed address means for TCP.
> Please make this an official Last Call issue.
Not sure what this means, but the documents you are discussing
is in WG LC. So this is a comment within the WG LC period.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 20:02:12 -0600

Michael,

Michael Tuexen wrote:                       (Tue, 17 Oct 2006 21:48:04)
> has crashed, which would most likely be an ABORT.

As you may, but I think it is unreasonable to force all other
implementations to view the world the same.  Receiving a valid ICMP
protocol unreachable might very well indicate that, for example, a
kernel module implementation has unloaded, however, depending on the
application, aborting the association in response is not necessarily the
right thing to do.  For carrier grade applications (e.g, SIGTRAN) the
assumption that the peer will recover very soon is valid.  Rather than
having a kernel module upgrade (removal then insertion) of very short
duration abort a bunch of associations, it is preferable to instead
persist in the associations and take advantage of SCTP's restart
procedures when the peer recovers.

So, as there is no security risk in sending to confirmed addresses (as
stated in 2960bis for normal data transmission), and there are no
interoperability concerns (all ICMP errors can be ignored for other
transport protocols), using MUST in that case is against the principle
of not using MUST arbitrarily to make an implementation do something a
certain way.

> I do not know what the concept of confirmed address means for TCP.

Following the definition in 2960bis, the destination address (one) on
the initiating side is confirmed (passed down by the user).

So tell my why an SCTP association that is single-homed on both ends
should not be able to behave the same way with regard to ICMP messages
as a TCP connection?

> is in WG LC. So this is a comment within the WG LC period.

I mean that this is not just an interesting discussion, it is a comment
and issue raised during WG LC on draft-ietf-tsvwg-2960bis.  If someone
is making a list of those, please place this on the list.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 18 Oct 2006 09:51:15 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> procedures when the peer recovers.
But, from an applications point of view, is the difference? If
your peer restarts, the application gets a COMM_LOST notification  
followed
by a COMM_UP indication or should behave like this when it gets
a restart notification. When it receives an ICMP(protocol unreachable)
or an ABORT it gets an COMM_LOST notification and if your peer (after
reloading the kernel module) establishes a new association it gets
an COMM_UP notification.

So for this scenario there is no difference for the application.
> So, as there is no security risk in sending to confirmed addresses (as
There is no known (by me) security risk...
> of not using MUST arbitrarily to make an implementation do something a
The MUST is OK because I think the ICMP is the same as an ABORT. So
it be handled the same way.
> the initiating side is confirmed (passed down by the user).
Yes.
> should not be able to behave the same way with regard to ICMP messages
Copying TCP is not a design principle for SCTP...
> is making a list of those, please place this on the list.
That is fine.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Oct 2006 03:00:15 -0600

Michael,

Michael Tuexen wrote:                    (Wed, 18 Oct 2006 09:51:15)
> So for this scenario there is no difference for the application.

As you know from the draft the difference is that during restart
the receiver of the restart (the peer receiving the ICMP) is not
required to discard data.  Also, that RESTART is indicated to the
user instead of COMM_LOST followed by COMM_UP.  So:

 ICMP(prot unreach)==ABORT discard data, tell user that data was
 discarded with COMM_LOST.

 INIT(restart) keeps data, tell user that data was kept with
 RESTART.

The later, again, being important for carrier grade signalling
applications and particularly SIGTRAN.

So there is a difference.

> it be handled the same way.

Well no, it is different as per above.

> Copying TCP is not a design principle for SCTP...

What is being redesigned by 2960bis ICMP8 is ICMP:
which already works fine, except for the security
threat to UNCONFIRMED multi-homed addresses--the
only characteristic that should be addressed by
ICMP8.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 18 Oct 2006 12:16:36 +0200

Brian,

a question inside...

Best regards
Michael

> As you know from the draft the difference is that during restart
Which draft are you referring to? When looking at RFC 3332 the CDI
is handled the same as the RI. Why can't you retrieve DATA after
a COMM_LOST indication?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Oct 2006 06:19:25 -0600

Michael,

Michael Tuexen wrote:                     (Wed, 18 Oct 2006 12:16:36)
> Which draft are you referring to?

draft-ietf-tsvwg-2960bis-02.txt

> is handled the same as the RI. Why can't you retrieve DATA after

Because an abortive disconnect flushes the read queues.  Provider reset
(restart) does not.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Oct 2006 16:50:00 -0400

Brian:

I will note down that you have asked to have ICMP8) changed..

As a refresher for those not following closely Currently ICMP8) states:
--------
    ICMP8)  If the ICMP code is a "Unrecognized next header type
       encountered" or a "Protocol Unreachable", an implementation MUST
       treat this message as an abort with the T bit set if it does not
       contain an INIT chunk.  If it does contain an INIT chunk and the
       association is in COOKIE-WAIT state, handle the ICMP message like
       an ABORT.
--------

Brian asks it to be changed to:
-------
-------

More details can be found in the thread:

Re: [Tsvwg] ICMP protocol unreachable
------------------------------------------------
Now, a question to others.. besides Michael and Brian..

Who else in the WG feels the same way as Brian?

Current standing of this issue:

For changing ICMP8)

    - Brian - Yes
*********
    - Michael T.  - No

Others please chime in here.. I will hold off on
my response until others have also chimed in :-)

R

---

From: "Meyknecht, Bernward" <[email-masked]>
Date: Wed, 25 Oct 2006 10:37:51 +0200

Hello Randy, all,

if you are interested in my opinion: I would leave the ICMP8
as it is, mainly for the reason, that the described possibility 
of a threat scenario can also be simply reached via sending faked
ABORTS, so we have no reason for change from point of view 
of robustness.

And I see no reason for this protocol change only for the purpose 
of living with firewalls, that do not behave as expected, in this 
case the firewall should be modified, and I think at least in any 
carrier grade environment the operator will surely take care that 
all his network elements support SCTP.

So take me to the 'no' list...

Best regards,

Bernward

-----Ursprüngliche Nachricht-----
Von: Randall Stewart [mailto:[email-masked]] 
Gesendet: Dienstag, 24. Oktober 2006 22:50
An: [email-masked]
Cc: Michael Tuexen; IETF Transport Area Mailing List
Betreff: [Tsvwg] SCTP-BIS LC issue 1

Brian:

For changing ICMP8)

    - Brian - Yes
*********
    - Michael T.  - No

R

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 25 Oct 2006 09:49:20 -0400

> Re: [Tsvwg] ICMP protocol unreachable

Hm...  One concern with a proposed text.  The address passed to the connect()
is considered CONFIRMED, so now this generates Max.Init.Retransmits (default 8)
INIT and ICMP messages, instead of 1 of each.  I think the text with regard to INIT
chunk needs to be put back.

Otherwise, I like the relaxed the version.  It allows the association to survive
a bit longer and potentially restart.  However, I don't think this will in any
way help the broken firewall problem since that shows up during the confirmation HBs.

I'll vote yes.

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 26 Oct 2006 15:58:50 -0400

Randall Stewart wrote:
> Vlad:
> 
> Ok status update...
> 
> 
> In favor of the change:
>   1
> 
> In favor of the change with a mod (no proposed text though :-0)
>   1

Sorry about that.  Poposed text would be:

ICMP8) If the ICMP code is an "Unrecognized next header type
   encountered" or a "Protocol Unreachable", an implementation MUST
   treat this message as an abort with the T bits set if it was sent to
   an UNCONFIRMED address.  If the message contained in the ICMP payload
   was sent to a CONFIRMED address, contains an INIT chunk, and the
   association is in COOKIE-WAIT state, it MUST handled like at ABORT.
   Otherwise, an implementation MAY ignore the ICMP message. 

In end, I am on the fence with this one.  Reason I voted yes is, this
change let's associations survive a bit longer without opening up any
security issues that I can see.

-vlad

> 
> Against any change
> 
>   3.
> 
> 
> I put three since after thinking it over and reading Bernward's response
> I think I will cast my vote in the "no change" camp..
> 
> R
> 
> 
> Vlad Yasevich wrote:
>> Randall Stewart wrote:
>>
>>> Brian:
>>>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 26 Oct 2006 15:45:34 -0400

Vlad:

Ok status update...

In favor of the change:
   1

Against any change

   3.

R