On Tue, 23 Apr 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> > I think we need to have a much much more clearer view of what is possible
> > and what is not when crossing zone boundaries with routing headers.
>
> I admit the notion is quite complicated and the text may have unclear
> points, but the described behavior is clear at least to me so that I
> could implement the rule in my implementation.
Did you write or participate in writing of the text? :-)
> So, could you be more
> specific about the unclearness? Could you give me a concrete example
> that cannot be explained with the description?
The text about the scope and zone of the source address and the previous
hop make the specification difficult to understand.
For regular packet forwarding, the second bullet in 9. basically seems to
say: "if you cross the zone boundary, the packet is discarded".
This should be, IMO, honoured with routing header too. In particular, one
should not be able (IMO) to control how routing should go inside a site,
using site-internal addresses (as these addresses aren't reachable to the
source, and may have a different level of security etc.). If the
destination site does not have global addresses in use there, he probably
don't want site-local's being used either.
Does does scoped arch work in the following case:
src=linklocalA
dst=globalB
routing header=linklocalB, segments left=1
Processing at globalB, I believe this would be discarded if linklocalA is
not a direct neighbor of globalB, correct? Processing at linklocalB, the
packet would always be accepted (if the proposed new rule is not adopted)?
Site-locals are potentially fishier as they can't be as trivially
restricted to a link.
I'd like to see a "roadmap" of what kind of forwarding is possible with
routing header, and what is not. I couldn't make a clear mental image
based on the text.
A comment,
Then the above forwarding rules are applied,
using the new destination address where the zone of the new
destination address should be determined by the scope of the previous
destination address and the interface to which the previous address
belongs (which is not necessarily equal to the incoming interface).
==> does incoming interface mean 'incoming interface' or 'incoming link'?
That is, can you use RH to forward packets out of the incoming link with
e.g. link-local addresses? (As in the previous paragraph in the text.)
Depending on the answer to that question, this may be in conflict with the
regular forwarding bullet above.
> > 14. Security Considerations
>
> > The routing section of this document specifies a set of guidelines
> > that allow routers to prevent zone-specific information from leaking
> > out of each site. If site boundary routers allow site routing
> > information to be forwarded outside of the site, the integrity of the
> > site could be compromised.
>
> > ==> Security considerations should mention potential problems of crossing
> > zone boundaries w/ routing headers.
>
> Okay, but the problems would basically be the same as in "normal"
> (i.e. all destinations are in the same scope type) routing headers.
> Do you have an example of the potential problems specific to the case
> of mixed scoped destinations?
Let's come back to this issue after the big picture of RH + scoping has
become clearer.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
