Re: [v6ops] IPv6 link-local traffic questions

On Sat, 21 Mar 2020, 14:00 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.
>

Can you guarantee a received packet with a Hop Count value of 1 hasn't been
forwarded?

You can when the received packet has a Hop Count of 255.

> 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
> --------------------------------------------------------------------
>