Subject: 6man w.g. last call for <draft-ietf-6man-icmp-limits-03>

From: Ole Troan <[email-masked]>
Date: Thu, 25 Jul 2019 14:18:33 -0400

Hello,

This message starts a new two week 6MAN Working Group Last Call on advancing:

  Title    : ICMPv6 errors for discarding packets 
             due to processing limits
  Author   : T. Herbert
  Filename : draft-ietf-6man-icmp-limits-03
  Pages    : 12
  Date     : 2019-05-29

    https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

as a Proposed Standard.  

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 8th of August 2019.

To improve document quality and ensure that bugs are caught as early as possible, we would at least require two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.

As discussed during the working group session, we will initiate the early allocation process for code points in this document as soon as we get the request from the author.

Thanks,
Bob & Ole, your 6man chairs.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2019 18:49:46 -0400

let me start with a minor nit:
>   Options may also be skipped
>   over by a receiver if they are unknown and the Option Type indicates
>   to skip (first two high order bits are 00).

I believe that this could read:

+ Options which are unknown by a receiver may be skipped if
+ the Option Type indicates to skip (first two high order bits are 00).

(While the "may" here is actually normative, it's not a normative statement of
this document)

I don't believe that this is merely editorial, as options which are known 
by the receiver may also be skipped.  Also some systems are configured
to skip all unknown headers, even when the first two higher order bits
are not 00.

and go on with my major issue:

This document refers to RFC4443 for security considerations
("The security considerations for ICMPv6 described in [RFC4443] are
applicable.") and RFC4443 says, "Just use IPsec", which RFC5406 explains is a
serious lack.  So for me, the Security Considerations are essentially still
empty!

I'm a bit unclear how much of the offending packet is to be returned.
The packet grows a bit bigger, but it's probably not enough to worry
about using these new codes for amplification attacks.  The security
considerations should deal with this concern.

There is significant text about how the sending node SHOULD log the packet,
and this also needs comment in the security considerations.  I doubt
that logging is really desired; rate limit queuing to the Upper-Layer,
perhaps to be retrieved by an extended recv() call that cares about things,
or doing something useful in the ULP...

Section 4.2 says it should validate that the ICMP is valid.
RFC4443 gives some rules, so please indicate if they are enough,
too much, or if we can do something extra.

It might be that I'm repeating conversations that already happened on
the ML or in person (I couldn't make 6man this week, I'll watch on
Youtube)... I have looked through the archives both for May 2019
and back to 2017. I see some conversations in May 2019 when I may have been
unsubscribed by mistake.   

I feel that there is a significant difference between ICMP messages
From random routers on the Internet, and ones from the receiving system.
This is what draft-hinden-6man-mtu-option has recognized as well, I think.

Basically, this is another ICMP PMTU situation and I think that these
messages will go the way of ICMP(v4) Source Quench.  This makes me sad.

I think that the problem that this document is trying to solve is very close
to the problem of MTU that draft-hinden-6man-mtu-option is trying to
solve. (If you consider the header limit as a kind of MTU!)

I like how draft-hidden-6man-mtu-option tries to collect information
along the path, and then has the receiver echo it back. It would be nice
to apply this model to future situations where the network has to
send ICMPs from random nodes (vs ICMPs from LL of your first hop router).
I can imagine a few solutions, but I think that they would be too impure
to be accepted, even if they might be more secure.

My objections to this document is that I don't think that any hosts will
be able to trust anything in these options, and therefore there is no value
in returning this information.  I also feel very sad having to say this!

So I'd like to know if there are transmitters who will find these
ICMPs sufficiently interesting and trustworthy that they would be willing
to implement reception of these ICMPs.  Perhaps in certain application
domains, things work.  (Maybe segment routing or something)

If so, then there we should be able to add an appropriate applicability
statement to this document and advance it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tom Herbert <[email-masked]>
Date: Tue, 30 Jul 2019 14:34:54 -0700

Hi Michael,

Thanks for the detailed comments. Some responses are inline.

> to skip all unknown headers, even when the first two higher order bits

Technically that woudn't be conformant. From RFC8200:

"The Option Type identifiers are internally encoded such that their
highest-order 2 bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type"

The "must" here is normative I believe. In particular, if a node skips
an unrecognized option with option type that indicates discard (i.e.
not 00 in first two bits of type) this may lead to incorrect
processing of the packet. Probably would be more of a problem for
Destination Options than HBH, options since the latter EH can ignored
by intermediate devices per RFC8200.

> serious lack.  So for me, the Security Considerations are essentially still

I'm not sure I understand your concern. Section 5.2 of RFC4443 lists a
number of attacks on ICMP and suggests mitigations beyond just using
IPsec (point 4 in the list suggests the use of rate limiting ICMP for
DOS mitigation for instance). Additionally, the ICMP errors described
in this draft are optional to send and allows with holding ICMP errors
in environments where security is an issue per second paragraph in
Security Considerations.

> considerations should deal with this concern.
In section 2.1, the ICMP message body is described by:

" As much of invoking packet as possible without the ICMPv6 packet
exceeding the minimum IPv6 MTU [IPv6]"

That is taken straight out of RFC4443. I don't see that the ICMP
errors defined in this draft would need other requirements in this
regard.

> too much, or if we can do something extra.
Okay. Will add a reference to RFC4443 and state any additional
validation that is needed.

> messages will go the way of ICMP(v4) Source Quench.  This makes me sad.
Perhaps, but I do believe there is value in defining these error
messages. These cover cases where nodes are already dropping packets
because it doesn't want to process them as opposed to anything being
wrong with the packets protocol-wise. Gaining some insight as to why
packets are being dropped, even if the messages aren't ubiquitous,
seems like a good thing.

> solve. (If you consider the header limit as a kind of MTU!)
The ICMP message was taken out of draft-hinden-6man-mtu-option; this
was done since in-lining the reported MTU in an EH on return packets
is more likely to succeed. In case of a node dropping packets there
are no obvious return packets to use to signal why packet was dropped,
hence the reason for out-of-band ICMP error.

> to be accepted, even if they might be more secure.
That is a good model. The equivalent procedure in this draft would be
something like mark the packet as being in error and forward to the
end host and let the end host decide the appropriate response. There
was a draft that pretty much did this in draft-leddy-6man-truncate-05
for PTB. I'm not sure that could be a general solution though.

> in returning this information.  I also feel very sad having to say this!
I don't think hosts need to trust the information as these would
should taken as just hints. In the current state affairs, packets are
dropped with no clue as to why; if ICMP errors are generated at least
the host might be able to do something reasonable. If the information
were to be completely falsified then the situation degenerates to the
same state we have to today-- a host might be able to deduce that
packets are being dropped, but has no idea why they are being dropped.

> statement to this document and advance it.

Sure, but I don't see anything special about these errors compared to
other ones that have been defined (e.g. port unreachable). ICMP may or
may not work on Internet and naturally has a better chance to work in
a limited domain.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 18:35:13 -0400

Tom Herbert <[email-masked]> wrote:
    >> This document refers to RFC4443 for security considerations ("The
    >> security considerations for ICMPv6 described in [RFC4443] are
    >> applicable.") and RFC4443 says, "Just use IPsec", which RFC5406
    >> explains is a serious lack.  So for me, the Security Considerations
    >> are essentially still empty!

    > IPsec (point 4 in the list suggests the use of rate limiting ICMP for

None of those mitigations apply to the receiver of the ICMPs who must figure
out which ICMPs are legitimate and which are not.  That is all advice on
being a good netizen.

    > exceeding the minimum IPv6 MTU [IPv6]"

So, the packet will grow.  I'd prefer that the resulting packet was always
limited to no bigger than the offending packet.  That's not what 4443 says,
but I think we have learnt alot of DDoS amplication since then.

    >> Youtube)... I have looked through the archives both for May 2019 and
    >> back to 2017. I see some conversations in May 2019 when I may have
    >> been unsubscribed by mistake.
    >> 
    >> From random routers on the Internet, and ones from the receiving
    >> system.  This is what draft-hinden-6man-mtu-option has recognized as
    >> well, I think.
    >> 

    > packets are being dropped, even if the messages aren't ubiquitous,

I can't argue with the desire to get feedback and gain insight into what is
going on.  I'm completely on your side here.  The question is, if a sender is
going to adapt to these signals, then it needs to know when/if/where it can
trust them.

    >> along the path, and then has the receiver echo it back. It would be
    >> nice to apply this model to future situations where the network has to
    >> send ICMPs from random nodes (vs ICMPs from LL of your first hop
    >> router).  I can imagine a few solutions, but I think that they would
    >> be too impure to be accepted, even if they might be more secure.
    >> 
    > something like mark the packet as being in error and forward to the end
    > host and let the end host decide the appropriate response. There was a
    > draft that pretty much did this in draft-leddy-6man-truncate-05 for
    > PTB. I'm not sure that could be a general solution though.

But, given that you want to measure something, the same hop-by-hop option
that the mtu-option document proposes could be used.  Insert it now and then
if there are issues, or if there is a belief that the path has changed.
We could even put some kind of nonce that would defeat off-path attackers,
and we'd have something we could really use.

    >> ICMPs sufficiently interesting and trustworthy that they would be
    >> willing to implement reception of these ICMPs.  Perhaps in certain
    >> application domains, things work.  (Maybe segment routing or
    >> something)
    >> 
    >> If so, then there we should be able to add an appropriate
    >> applicability statement to this document and advance it.

    > may not work on Internet and naturally has a better chance to work in a
    > limited domain.

Port unreachable comes from the destination host, and comes with the
destination hosts' IP, and can if you use host-to-host IPsec, actually be
sent via IPsec on an existing SA.

If it can work in a limited environment, then could you tell us of some
operators of such limited environments that would find these signals useful
enough that they would want their end points to include code to observe
these?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tom Herbert <[email-masked]>
Date: Tue, 30 Jul 2019 16:12:53 -0700

Michael,

Responses in-line...

> out which ICMPs are legitimate and which are not.  That is all advice on

There is a certain amount of validation that occurs on the packet in
error. For instance, the addresses and ports can be validated.
Processing rules an verification of ICMP errors are discussed in
section 2.4 of RFC4443, the errors defined here are subject to those
rules.

> but I think we have learnt alot of DDoS amplication since then.
Sorry, I still don't understand the concern. I don't seen that this
draft is introducing any requirement for ICMP errors not already in
RFC4443.

> sent via IPsec on an existing SA.
PTB might have been a better example. PTB errors should have the same
attributes with respect to security and trustworthiness of
information.

> enough that they would want their end points to include code to observe

One example I can mention is segment routing extension header which is
intended on for use in a limited domain. By design, segment routing
requires intermediate nodes to inspect the segment routing header.
It's also inherent in the design that segment routing headers can be
quite large in terms of number of bytes, for instance each SID is
sixteen bytes and there may be TLVs on top of the SID list so a single
SRH may be hundreds of bytes in size. We know that hardware devices
have limits on the aggregate length of headers they can process. Some
have a 128 byte limit, some have a 256 byte limit, etc. Now suppose
that an SRH exceeds the limit of one of the intermediate destinations
in the routing list; I believe today the result is the packet is
silently discarded. If an ICMP error is sent then the sender will know
that the SRH is too big and take some corrective action like using a
shorter SID list. The ICMP error can be validated as being sent from
one of the nodes in the SID list and the Segement Routing Domain is
presumed to be a secure environment. Also note the similarity between
this situation and when the packet is discarded because HMAC
verification fails when ICMP parameter problem with code 0 is sent.

Tom

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 20:13:49 -0400

Tom Herbert <[email-masked]> wrote:
    >> If it can work in a limited environment, then could you tell us of
    >> some operators of such limited environments that would find these
    >> signals useful enough that they would want their end points to include
    >> code to observe these?

    > verification fails when ICMP parameter problem with code 0 is sent.

Thank you!
This would be a great applicability statement.

I think that the document would be greatly improved and will pass security
review far easier if it limits itself to specific environments such as SRH.
I think that origin validation is greatly simplified for SRH, since the
packets will all come from routers in the SRH, and will be to other routers
in the same Segment Routing Domain.

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Jul 2019 14:36:54 +1000

Hi,

I support this draft being advanced, as I think it would be very
useful when identifying the cause of packet loss.

I do think the following text needs some further clarification and discussion:

"A source host that receives an ICMPv6 error can modify its
   use of extension headers in subsequent packets sent to the
   destination in order to avoid further occurrences of packets being
   discarded."

I think it is important to point out in this ID that ICMPv6 messages
cannot be relied upon, as they may not be sent due to sender ICMP rate
limits, may not arrive due to packet loss or filters along the path,
and are not retransmitted to overcome initial ICMPv6 message loss.

With a quick search of RFC 4443 for terms "loss", "lost", "reliab" and
"filter", I can't seem to find any more general discussion about
ICMPv6 filtering and lack of reliability through retransmission that
could be referenced.

I too am reminded of the deprecation of Source Quench and PMTUD problems.

I still think this is very worthwhile for troubleshooting. Having an
idea of what the cause of and where packet loss is occurring, even if
that indicator is not 100% reliable, is much better than trying to
troubleshoot silent packet loss. Ideally we want to keep the cause of
absolutely silent packet loss limited to a single cause of congestion
being encountered. (Although silent loss also commonly occurs due to
packet filters/ACLs/firewalls, there is an ICMPv6 message for that, so
it can be indicated if desired.)

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jul 2019 15:52:44 -0700

Mark,

Thanks for the comments. Some replies in line...

> and are not retransmitted to overcome initial ICMPv6 message loss.
Okay, will add text pointing this out.

> ICMPv6 filtering and lack of reliability through retransmission that

That's not surprising. ICMP is just one example of protocols that
might have problems making it through the Internet. I don't believe
there's any IETF protocol that relies on ICMP to be reliable, nor will
there ever be.

> it can be indicated if desired.)

Agreed. IMO, silent loss should only be happening for transient
conditions like transmission errors and congestion. Drops for
non-transient reasons should result in an errors (with exceptions in
security or filtering as you point out). Another value of this is to
convey a cost (at least in spirit) to middleboxes for arbitrarily
dropping packets for reasons outside of the protocol specification.

Tom