Subject: scoping-arch and link-local addresses in RH

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Apr 2002 18:45:22 +0300 (EEST)

Hello,

Elena Vengerova <[email-masked]>, in an email exchange, brought up some 
need for clarifications wrt. scoped addresses and routing header.
This made me look deeper in to the scoping arch document.

A few comments:

9. Forwarding
[...]

           o After the next-hop interface is chosen, the zone of the
              source address is considered.  As with the destination
              address, the zone of the source address is determined by
              the scope of the address and arrival interface of the   
              packet.  If transmitting the packet on the chosen next-hop
              interface would cause the packet to leave the zone of the 
              source address, i.e., cross a zone boundary of the scope
              of the source address, then the packet is discarded and an
              ICMP Destination Unreachable message [RFC 2463] with Code 
              2 ("beyond scope of source address") is sent to the source
              of the packet. 

==> Note the wording about crossing zone boundary w/ source address.

[...]

   A node that receives a packet addressed to itself and containing a
   Routing Header with more than zero Segments Left [RFC 2460, section
   4.4] swaps the original destination address with the next address in
   the Routing Header.  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).  
   An implementation MUST NOT examine additional addresses in the 
   Routing header to determine whether they are crossing boundaries for
   their scopes.  Thus, it is possible, though generally inadvisable, to
   use a Routing Header to convey a non-global address across its 
   associated zone boundary. 

==> Wow, a 5-line sentence :-).  Anyway, my imagination is failing here 
what kind of non-global addresses can be placed in the routing header?
There may be a conflict with the previous comment there.

E.g are you able to send a packet like:

src=global1
dst=globalA
routing header=site_localA, segments left=1

which would be translated at globalA to:

src=global1
dst=site_localA
routing header=globalA, segments left=0  ?

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.

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.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 11:21:32 +0900

>>>>> On Mon, 22 Apr 2002 18:45:22 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> routing header=globalA, segments left=0  ?

According to the draft, correct.

> 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.  So, could you be more
specific about the unclearness?  Could you give me a concrete example
that cannot be explained with the description?

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

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Apr 2002 09:24:51 +0300 (EEST)

On Tue, 23 Apr 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> could implement the rule in my implementation.  

Did you write or participate in writing of the text? :-)

> So, could you be more

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, 

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

> of mixed scoped destinations?

Let's come back to this issue after the big picture of RH + scoping has
become clearer.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 16:56:51 +0900

>>>>> On Tue, 23 Apr 2002 09:24:51 +0300 (EEST), 

> Did you write or participate in writing of the text? :-)

The answer depends on the definition of "the text" and "participate
in":-)

Though I'm a co-author of the draft, I have basically contributed the
textual representation section only.  For other sections, I'm almost a
reader of the draft, just like you.

> say: "if you cross the zone boundary, the packet is discarded".

This is oversimplification.  The second ballet says "a packet must not
cross the zone boundary of the source address's zone".

> This should be, IMO, honoured with routing header too.

As for the source address, that's correct (or at least what the draft
intended to say).

> In particular, one 

Sorry, I don't understand the statement above.  Could you be more
specific please?

> not a direct neighbor of globalB, correct?

Correct.

> Processing at linklocalB, the 

If all the 3 addresses are in the same link, yes.  Otherwise, no.

> routing header, and what is not.  I couldn't make a clear mental image

I'm not sure what "roadmap" exactly means, but the restriction that
Rich mentioned will be clearer about the rule...

> ==> does incoming interface mean 'incoming interface' or 'incoming link'?  

It means 'incoming interface' (or 'arrival interface').

> e.g. link-local addresses?  (As in the previous paragraph in the text.)

That depends on the precise configuration, as I said above.

					JINMEI, Tatuya

p.s. to make my position clear, I'm not a fan of the current rule.
Formerly I proposed a stricter rule that required all destinations in
a routing header were in the same scope type for deterministic
behavior.  But the consensus at that time was that the flexible rule
was supported.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Apr 2002 12:25:46 +0200

In your previous mail you wrote:

   9. Forwarding
   [...]
   
=> this is clear: the next destination must not be outside the source zone.
I don't believe there is something to discuss for this point.
   
   [...]
   
=> there are two points:
 - how to determine the zone of the next destination (as addresses
don't carry the id of the zone but only the scope, this is very useful).
 - do it only on the next destination address, no further
   (note this is a consequence of the previous point).
Only the wording is questionable... (i.e. I can't see a concern for
other thing than the form)

=> as the rules forbid this there is no need for extra considerations.

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Apr 2002 23:44:04 +0300 (EEST)

> I don't believe there is something to discuss for this point.

Perhaps the draft should say it as you did. :-)

> other thing than the form)

My main gripe was the wording: upon the first look, it was rather 
difficult to see what was actually meant.

> => as the rules forbid this there is no need for extra considerations.

This would appear to be in conflict what it says in the draft:

           Thus, it is possible, though generally inadvisable, to
   use a Routing Header to convey a non-global address across its
   associated zone boundary.

or is there some nuance I'm missing?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Apr 2002 00:00:32 +0300 (EEST)

> cross the zone boundary of the source address's zone".

Ok.
 
> As for the source address, that's correct (or at least what the draft

Routers N hops away may have difficulties in determining this with a 
certainty.
 
> Sorry, I don't understand the statement above.  Could you be more

AFAICS, the following is allowed:

Assume sites A and B.

src=globalA
dst=globalB
routing header=sitelocalB, global2B
segments left=2

So source A is able to control how globalB inserts a packet from a global 
source to site _B_'s internal, site-local routing system.  You could of 
course also, after using the routing system, revert the destination back 
to some global one.

My point here was: anyone from site A should not be able tell how site B 
should route packets using _site-local_ addresses?
 
> Rich mentioned will be clearer about the rule...

I'd like to know what people vision RH + scoping would be useful for.

Then it might be easier to decide whether a simpler approach would be 
appropriate.
 
> That depends on the precise configuration, as I said above.

I'm not sure if that's obvious from the text.

> behavior.  

I tend to agree.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Apr 2002 11:57:27 +0200

=> perhaps you don't understand the draft remark: the idea is there may be
a non-global address in previous destinations which is outside of the
current zone. I believe this is no security issue or utility for this
feature.

Regards