Subject: comments from Steve Bellovin on draft-ietf-ipv6-scoping-arch-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 13 Aug 2004 19:18:12 +0900

Hello,

Thanks for your feedback on draft-ietf-ipv6-scoping-arch-01.txt in
IESG evaluation.

Below are my proposed resolutions to your comments.  I'm planning to
submit a new revision of the draft containing the resolutions next
week.  Any comments on the proposal by then would be highly
appreciated.

For reference, the full text of (the candidate of) new revision is
available at: http://www.jinmei.org/draft-ietf-ipv6-scoping-arch-02rc1.txt

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

> Steve Bellovin:
> Discuss:
> [2004-07-06] The Security Considerations section should note that the 
> ambiguity of addresses means that unqualified source IP addresses 
> cannot safely be used in security contexts such as ACLs or IKE 
> negotiation.

Proposed resolution:

add the following paragraph at the head of security considerations
section:

   The ambiguity of limited scope addresses has security implications.
   In particular, unqualified source IP addresses regarding their scope
   cannot safely be used in security contexts such as access control
   lists or key negotiations for IP security.

> Comment:
> [2004-07-06] The discussion of convex routing in Section 5 should 
> probably note that tunneled links are excluded from the prohibition.

Proposed resolution:

add the following sentence to the last bullet of the "additional
properties" list in Section 5:

      [...]  Note, however,
      that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6
      tunnel link [8]), a lower layer network of the tunnel can be
      located outside the zone without breaking the convexity property.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 13 Aug 2004 19:23:52 +0900

Hello,

Thanks,

					JINMEI, Tatuya

> Ted Hardie:
> Comment:
> [2004-07-08] In Section 6:

>        A tunnel interface (e.g., the abstract endpoint of an
>        IPv6-over-IPv6 tunnel [8], presumably established over either the
>        Ethernet or the point-to-point link.)

> COMMENT:  In general, this is a very helpful example.  I would
> suggest, though, that defining the tunnel interface as established
> over the Ethernet might help illustrate the point that it gets
> its own link-local zone, where two interfaces to the same Ethernet
> link do not.  Not strictly necessary, but it would be a good opportunity
> to make the point.

Proposed resolution:

I'm not 100% sure if I understand the point of the comments, but how
about revising the following paragrah in Section 6:

   Because the two Ethernet interfaces are attached to the same link,
   the node is attached to only four link-local zones, identified by
   link indices 1 through 4.

to:

   Because the two Ethernet interfaces are attached to the same link,
   the node is attached to only four link-local zones, identified by
   link indices 1 through 4.  Also note that even if the tunnel
   interface is established over the Ethernet, the tunnel link gets its
   own link zone, which is different from the zone of the Ethernet link.

(i.e, adding the second sentence)

---

From: Francis Dupont <[email-masked]>
Date: Sun, 15 Aug 2004 19:19:01 +0200

In your previous mail you wrote:

   
   Proposed resolution:

   
=> IMHO the proposed resolution is not enough accurate: there is a real
issue with scoped addresses and IKE which is not really addressed.
It has been known since many years, I remember some message exchanges
with Itojun about this (I proposed a fix for racoon, the KAME IKE
implementation). Fortunately I have a text about this issue in
my MIPv6/IPsec framework draft which I translated to xml two days ago
in order to refresh it... I put it as it is at the end of this message.

Regards

[email-masked]

PS: please ask if you need help to understand my text or to adapt
it to your draft.
PPS: some details:
 - the original text is pretty old (feb 2002)
 - the SCOPING reference is the scoping architecture draft
 - the term partition comes from mathematics

    <section anchor="scoped" title="Scoped Addresses">
    <t>
    This topics is not really a Mobile IPv6 one, but in practice the
    "mobile VPN" case there is a heavy usage of limited scope or
    private addresses.
    </t>

    <t>
    The issue is that addresses carried in identity or traffic
    selector payloads are not clothed with zone identifiers.
    Only the peer addresses used to transport messages have an
    indirect indication of their zones.
    </t>

    <t>
    The IPv6 address architecture <xref target="SCOPING" /> gives
    the properties
    of zones: at a given scope, zones formed a partition, i.e.,
    an interface belongs to one and only one zone. They have an
    inclusion property too, i.e., a zone of a given scope is
    fully included into a zone of any higher scope. This gives
    an inheritance property which is safe when it is used in
    the proper way: to establish SAs with global addresses with
    IKE running over link-local addresses is safe, the opposite
    is not.
    </t>

    <t>
    <iref item="RULE" subitem="" />
    RULE: The default policy SHOULD accept scoped addresses as
    selectors of SAs only when they are established using peer
    addresses (for the transport of IKE/IKEv2/etc messages) which
    are in fully included zones.
    </t>
    </section>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 14:21:33 +0900

>>>>> On Sun, 15 Aug 2004 19:19:01 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

   

> in order to refresh it... I put it as it is at the end of this message.

Please let me check...are you saying something like this?

The proposed text says:

  unqualified IP addresses cannot safely be used for IKE negotiation.

but, for example, we should (safely) be able to perform IKE
negotiation for an SA with link-local addresses if the IKE packets are
sent from/to the link-local addresses (since then the appropriate zone
can be determined from the zone of the IP packets).

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Aug 2004 11:20:53 +0200

The proposed text says:

=> unqualified is not accurate enough: the idea is about scoped addresses
without scope IDs. And the issue is not only for IKE, it is for any
similar protocol not using scope ID (not clothed address).

=> the example is correct but IMHO an example where the negociation is
not safe (IKE runs over global addresses with traffic selectors using
bare link-local addresses) is better.

Thanks

PS: note that I believe this is the proper fix, i.e., we should not add
scope IDs to IKE/IPsec.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 18:26:54 +0900

>>>>> On Mon, 16 Aug 2004 11:20:53 +0200, 

   

   
> bare link-local addresses) is better.

So, if I understand you correctly, your points are

- use "scoped addresses without scope IDs" instead of "unqualified
  address"
- make sure that the issue of IKE is just one example (I think the
  original proposed text was clear on this though)

Then how about the following change?

Proposed resolution (old)

Proposed resolution (new)

   A limited scoped address without its zone identifier value has
   security implications, and cannot be used for some security
   contexts.  For example, a link-local address cannot be used as a
   part of a security association for Internet Key Exchange (IKE) when
   the IKE packets are carried over global addresses.  Also, a
   link-local address without its zone identifier cannot be used in
   access control lists.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Aug 2004 17:21:31 +0200

=> we have almost finished:

   
   Proposed resolution (better)
   
      A limited scoped address without its zone identifier value has
      security implications, and cannot be used for some security
      contexts.  For example, a link-local address cannot be used in
      a traffic selector of a security association established by
      Internet Key Exchange (IKE) when
      the IKE messages are carried over global addresses.  Also, a
      link-local address without its zone identifier cannot be used in
      access control lists.
   
Thanks

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Aug 2004 19:35:24 +0900

>>>>> On Tue, 17 Aug 2004 17:21:31 +0200, 

   

>       link-local address without its zone identifier cannot be used in

Basically, I don't have a problem with your suggestion, but I have a
couple of questions:

1. Isn't the notion of "traffic selector" specific to IKEv2?  If so,
   should we explicitly say IKEv2 in the example?
2. I'm not sure if "a traffic selector of a security association" is
   the accurate wording.  If we really want to use the notion of
   "traffic selector", shouldn't we rather simply say "traffic
   selector" (without security association)?

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Aug 2004 22:50:59 +0200

=> the term is but not the notion. In fact the notion is from the
architecture (RFC 2401) when SPD (Security Policy Database) entries
are described. IMHO this is a good example of what the proper terminology
can give, so why sulk it?

      the accurate wording.

=> there are many possible addresses related to a security association
(1 to 4 in RFC 2401, IKE and PF_KEY) so we need to be as accurate as
possible.

      If we really want to use the notion of
      "traffic selector", shouldn't we rather simply say "traffic
      selector" (without security association)?
   
=> I don't know. Of course this is not ambiguous for me...
Perhaps it is time to get an advice from our security area director?

Thanks

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 2004 12:15:46 +0900

>>>>> On Wed, 18 Aug 2004 22:50:59 +0200, 

> can give, so why sulk it?

I don't mind to use the term "traffic selector", but I'm wondering
if it might be better to use IKEv2.

   
> Perhaps it is time to get an advice from our security area director?

Perhaps, but I don't know if we can expect an answer considering the
silence so far...

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 2004 16:19:07 +0900

>>>>> On Thu, 19 Aug 2004 12:15:46 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> Perhaps, but I don't know if we can expect an answer considering the

I've checked the wording with IKE experts around me and concluded that
your proposed text was fine.  It would be good if we can get
confirmation from the AD(s), but I'll submit the new revision
containing the changes we've made so far within about 24 hours.

Hopefully we'll be done then.

Just for reference, the version I'm planning to submit is available
at:
http://www.jinmei.org/draft-ietf-ipv6-scoping-arch-02rc2.txt

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 19 Aug 2004 09:20:16 +0200

=> as the issue is generic we can use IKE or IKEv1 or IKEv2. I prefer
IKE because it will cover both IKEv1 and IKEv2 in minds.

   
=> we have to wait for an answer in any case (:-)...

Thanks

PS: for me as the editor you are the master for style details.