On Thu, 3 Jan 2019, Andrew Cagney wrote:

 initiate on demand from 1::1:8 to 2::2:0 proto=1 because: acquire

So the above is simply a bug - :to's port should have been non-zero.

Well no. proto=1 is ICMP, which has no ports :)

If you _really_ want you could translate back from port to type and show
the ICMP type, provided the XFRM ACQUIRE contains this info as per RFCs:

https://tools.ietf.org/html/rfc7296#section-3.13.1

      ICMP and
      ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
      represented in this field as specified in Section 4.4.1.1 of
      [IPSECARCH].  ICMP Type and Code values are treated as a single
      16-bit integer port number, with Type in the most significant
      eight bits and Code in the least significant eight bits.  MIPv6 MH
      Type values are treated as a single 16-bit integer port number,
      with Type in the most significant eight bits and the least
      significant eight bits set to zero.

https://tools.ietf.org/html/rfc4301#section-4.4.1.1

           If the Next Layer Protocol value is ICMP, then there is a
           16-bit selector for the ICMP message type and code.  The
           message type is a single 8-bit value, which defines the type
           of an ICMP message, or ANY.  The ICMP code is a single 8-bit
           value that defines a specific subtype for an ICMP message.
           For IKE, the message type is placed in the most significant 8
           bits of the 16-bit selector and the code is placed in the
           least significant 8 bits.  This 16-bit selector can contain a
           single type and a range of codes, a single type and ANY code,
           and ANY type and ANY code.  Given a policy entry with a range
           of Types (T-start to T-end) and a range of Codes (C-start to
           C-end), and an ICMP packet with Type t and Code c, an
           implementation MUST test for a match using

               (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
               C-end

           Note that the ICMP message type and code may not be available
           in the case of receipt of a fragmented packet. (See Section
           7, "Handling Fragments".)

Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev

Reply via email to