Re: [v6ops] IPv6 link-local traffic questions

On Fri, Mar 20, 2020 at 7:59 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
>
> On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda <tonysietf@gmail.com>
> wrote:
>
>> Yepp, that's personally I prefer on multicast TTL=1 (and also on ISIS &
>> e.g. on expired draft where we were carrying ISIS natively over IP). The
>> cost of a frame running away unintended multiple-hops in a control protocol
>> without a tunnel are simply NOT fun.  The cost of such a thing (and it
>> happened MORE than once) outweighs IMO the minor security advantage.
>>
>> If you read v6 BIER drafts you should read
>> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has
>> been published much, much earlier ...
>>
>> --- tony
>>
>> TTL security is a necessity for ND with limited risk of run away ND
>> packets as it’s  minimal bandwidth usage.
>>
>
>    With a multicast stream the risk is much greater if forwarded multiple
> hops past the BFER PE as stated and maybe a high data rate stream so
> undesirable to ever happen.
>
>  ND is the only protocol I know of that uses TTL security.
>
> I would go with TTL=1.
>

Certainly RFC 4861 message validation sections say the message has to have
a hop limit of 255, so it should go without saying that the spec should be
followed where such text exists.

Also BGP and other routing protocols can use hop limit security.  GTSM (
https://tools.ietf.org/html/rfc5082).  Specifically:
https://tools.ietf.org/html/rfc5082#section-5.1

If security is a concern in the v6 tunnel, is it possible to add
> cryptography to BIER or even setting security TLV in the BIER header
> encoded in the DO on the BFIR and then validate the TLV encoding on the
> BFER destination endpoint.
>
>
>
>> On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <hayabusagsm@gmail..com
>> <hayabusagsm@gmail.com>> wrote:
>>
>>>
>>> Toreless & Tony
>>>
>>> I read through the draft for BIER over IPv6.
>>>
>>> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06
>>>
>>> So since the BIER header bitmask that denotes the BFERs in the Domain to
>>> replicate the multicast packets is encoded in the DestOp processed by the
>>> BFER, the packets should not be forwarded past the BFER is my guess is with
>>> ttl 255.  With IPv6 ND with ttl 255 example the packet can be forwarded
>>> past the adjacent node but I have not seen that happen.  I believe Jen
>>> Linkova on this thread has seen that. Since the BFER dest options has to
>>> have the BIER bit mask encoding or the packet is dropped I believe is your
>>> security protection from forwarding past the BIER with 255 ttl if you
>>> decided to go that route.
>>>
>>> Under BIERv6 packet processing should help if ttl 255 is used to prevent
>>> forwarding outside of bier domain
>>>
>>> A packet having a 'BIER Specific Handling' indication but not having
>>>    a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
>>>    and the process can be refered to the example in section 3.2 <https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-3.2>.
>>>
>>>    A packet not having a 'BIER Specific Handling' indication but having
>>>    a BIER option SHOULD be processed normally as unicast forwarding
>>>    procedures, which may be a behavior of drop, or send to CPU, or other
>>>    behaviors in existing implementations.
>>>
>>>
>>> Under 5.3 security considerations should also help with ttl 255 and
>>> forwarding outside of BIER domain
>>>
>>> For a router incapable of BIERv6, such BIERv6 packet will not be
>>>    processed by the procedure described in this document, but be
>>>    processed as normal IPv6 packet with unknown option, and the existing
>>>    security considerations for handling IPv6 options apply.  Possible
>>>    way of handling IPv6 packets with BIER option may be send to CPU for
>>>    slow path processing, with rate-limiting, or be discarded according
>>>    to the local policy.
>>>
>>>    For a router capable of BIERv6, such BIERv6 packet MUST NOT be
>>>    forwarded, but should be processed as a normal IPv6 packet with
>>>    unknown option, or additionally and optionally be countered and
>>>    logged if the router is capable of doing so.
>>>
>>>
>>> Kind regards
>>>
>>> Gyan
>>>
>>> On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Makes sense.
>>>>
>>>> Thanks
>>>>
>>>> Gyan
>>>>
>>>> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer <kauer@biplane.com.au> wrote:
>>>>
>>>>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
>>>>> > I always wondered why RFC 4862 states that ND & RD packets have TTL
>>>>> > 255.
>>>>>
>>>>> >From RFC4861:
>>>>>
>>>>>    "By setting the Hop Limit to 255, Neighbor Discovery
>>>>>     is immune to off-link senders that accidentally or
>>>>>     intentionally send ND messages.  In IPv4, off-link
>>>>>     senders can send both ICMP Redirects and Router
>>>>>     Advertisement messages."
>>>>>
>>>>> RFC4861 also requires RA and NA packets with any other TTL value to be
>>>>> silently discarded by any receiving node.
>>>>>
>>>>> I can't find my original source, but my notes in a training course I
>>>>> developed a while ago have this to say about why:
>>>>>
>>>>>    "Why does 255 mean “local source”? Because routers
>>>>>     decrement the hop limit on packets passing through
>>>>>     them, and discard packets where the hop count
>>>>>     decrements to zero. It is impossible to decrement
>>>>>     a one-byte counter to 255 without passing through
>>>>>     zero, because 255 is the maximum value such a counter
>>>>>     can have. So the value 255 means that the packet must
>>>>>     have been generated on the local link."
>>>>>
>>>>> Probably would be better expressed as "must have originated on the
>>>>> local link".
>>>>>
>>>>> Regards, K.
>>>>>
>>>>> --
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> Karl Auer (kauer@biplane.com.au)
>>>>> http://www.biplane.com.au/kauer
>>>>> http://twitter.com/kauer389
>>>>>
>>>>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
>>>>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> v6ops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>> --
>>>>
>>>> Gyan  Mishra
>>>>
>>>> Network Engineering & Technology
>>>>
>>>> Verizon
>>>>
>>>> Silver Spring, MD 20904
>>>>
>>>> Phone: 301 502-1347
>>>>
>>>> Email: gyan.s.mishra@verizon.com
>>>>
>>>>
>>>>
>>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>>
>>>
>>> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>