Hi Brian,
Thanks a lot for the comments.
> I don't quite understand that. Does it mean to check that none of
> the n addresses in the RH4 matches any of the current node's
> interface addresses? But at least one of them must match, since
> packet was delivered to the current node.
The RFC2460 clearly states that:
A Routing header is not examined or processed until it reaches the
node identified in the Destination Address field of the IPv6 header.
Page 17 gives an example and clearly states how the routing header
changes as the packet traverses the network. None of the address in
the routing header match the current node address only the destination
address in the IPv6 header does.
> > Whereever possible, including the administrative network edge, RPF check
> > needs to be done.
> If RH4 is being used to diagnose routing configuration errors,
> an RPF check is quite likely to fail, so this recommendation
> seems to defeat one of the purposes of RH4.
That is a very good point. I agree most of the attack vectors get
reduced once we have the limit in the number of LSA's. That is the
reason this part has just been added as a recommendation to the
Security consideration section.
I will update the draft with your comments, as well as add a section
of the uses of RH header, and update the draft.
Thanks,
Vishwas
On 9/11/07, Brian E Carpenter <[EMAIL PROTECTED]> wrote:
>
> > else {
> > Compare the addresses in the Routing Header to check that
> > none of the address belong to the routers self address
> >
> > if overlapping address exist {
> > discard the packet
> > }
>
> I don't quite understand that. Does it mean to check that none of
> the n addresses in the RH4 matches any of the current node's
> interface addresses? But at least one of them must match, since
> packet was delivered to the current node.
>
> > 4. Security Considerations
> ...
> > Whereever possible, including the administrative network edge, RPF check
> > needs to be done.
>
> If RH4 is being used to diagnose routing configuration errors,
> an RPF check is quite likely to fail, so this recommendation
> seems to defeat one of the purposes of RH4.
>
> Brian
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
