Subject: [CGA-EXT] Review of draft-ietf-csi-sndp-prob-00

From: Julien Laganier <[email-masked]>
Date: Wed, 17 Dec 2008 16:14:59 +0100

I have reviewed draft-ietf-csi-sndp-prob-00. These are my comments:

Review Summary:
---------------

Section 2: the scenario part does overall a good job at sketching 
current usage of ND proxies (altough it misses the PMIPv6 use case that 
we documented in draft-ietf-csi-proxy-send) and discussing why it break 
SENDs. 

Section 3 is a bit lost, I'm feeling it overlaps with Section 2 and thus 
should be merged with it.

Section 4 and 5 are IMHO reaching far too much into solution space, yet 
the document hasn't slated a trust model for operating ND proxies, 
which I think is clearly part of the problem statement. 

Thus I feel I'm missing the most important part of the problem 
statement. What I'd like to see is a document structured around one or 
more documented trust model (maybe aking to what RFC 3756 did), 
explaining what the ND proxy does, who owns it, what authority it has 
and where it gets it from. There can be one or more trust model 
depending on their applicability to different usage scenarios (e.g. 
bridge like ND proxies, MIPv6 HA proxying, PMIPv6 MAG proxying). Then 
there can be the explanation why the current SEND isn't sufficient for 
each of the trust model.

Then I think we are done with the problem statement and we do not need 
the part on "potential approaches to secure proxy ND" as in section 5 
of the current document, which belongs to solution space IMHO.

Detailed Review:
----------------

I had started a detailed review, wordsmithing etc. but I stopped within  
Section 4.2 when I realized the document structure wasn't convincing to 
me and thought I'd better give high level comments rather than sentence 
level suggestions. FWIW I'm anyway copying the beginning of detailed 
review I performed below. 

2.1.  IPv6 Mobile Nodes and Neighbor Discovery Proxy
----------------------------------------------------

"  When moving in the Internet, the aim of IPv6 mobility is to allow a
   device continued packet delivery, whether present on its home network
   or not.  The following text is focused on Mobile IPv6 but the issue
   is the same with Mobile IPv6 based protocols (e.g.  NEMO, HMIPv6).
"

The text about the "issue" above is confusing. 

First, what is the "issue"? Is this the general issue of maintaining 
existing communications for mobile hosts, or is it specific to the 
neighbor discovery proxy function introduced to cope with the existence 
of the home link. That should be clarified.

Second, if the "issue" is with the Neighbor Discovery Proxy function, I 
understand that there's no "issue" with HMIPv6 because HMIPv6 has no 
notion of home link per se and thus does not need a ND proxy function.

Third, if the "issue" is with maintaining existing communications for 
mobile hosts, I do not think we need to talk about HMIPv6 there since 
this document is not a problem statement for a mobility protocol.

"  [...]

   If Cryptographically Generated Addressing (CGA) [RFC3972] is 
   available, the MN may be able to secure its Neighbor cache bindings
   while at home using Secured Neighbor Discovery (SEND) [RFC3971].
   SEND assumes that the address owner is the advertiser and therefore
   has access to the keys required to sign advertisements about the
   address.  Movement away from the home link requires that a proxy
   undertake Neighbor Discovery.

   In Mobile IPv6, the role of the proxy is undertaken by the Home
   Agent.  While the Home agent has a security association with the MN,
   it as proxy will not have access to the public-private key pair used
   to generate the MN's cryptographic address.  This prevents Proxy
   Neighbor Discovery from using SEND as defined [RFC3971].

   Where a host moves from the home network to a visited network, the
   proxy needs to override existing valid Neighbor cache entries which
   may have SEND protection.  This is needed in order to redirect
   traffic to use the proxy's link-layer address, allowing packets to
   flow onto the tunnel connecting the Home Agent/Proxy and the MN.
   With current specifications, any solicitation or advertisement sent
   by the proxy will not be able to update the MN's home address if the
   existing NC entry is protected by SEND.  Such existing Neighbor cache
   entries will time-out after Neighbor Unreachability Detection
   [RFC4861].
"

Suggest rewording:

While at home, if the MN has configured Cryptographically Generated 
Addresses (CGAs) [RFC3972], it can secure establishment by its on-link 
neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using Secure 
Neighbor Discovery (SEND) [RFC3971]. SEND security requires a node 
sending Neighbor Advertisments for a given address to be in possession 
of the public-private key pair that generated the address.

When a MN moves away from the home link, a proxy has to undertake 
Neighbor Discovery signaling on behalf of the MN.  In Mobile IPv6, the 
role of the proxy is undertaken by the Home Agent. While the Home agent 
has a security association with the MN, it does not have access to the 
public-private key pair used to generate the MN's CGA. Thus the Home 
Agent acting as an ND proxy cannot use SEND for the address it is 
proxying [RFC3971].

When a MN moves from the home network to a visited network, the proxy 
will have to override the MN's existing Neighbor Cache Entries which 
are flagged as secure [RFC3971]. This is needed for the Home Agent to 
intercept traffic sent on-link to the MN that would otherwise be sent
to the MN's link layer address.

With the current SEND specification, any solicitation or advertisement 
sent by the proxy will be unsecure and thus will not be able to update 
the MN's NCE for the home address because it is flagged as secured. 
These existing Neighbor Cache Entries will only time-out after Neighbor 
Unreachability Detection [RFC4861] concludes the Home Address is 
unreachable at the link layer recorded in the NCE.

2.2.  IPv6 Fixed Nodes and Neighbor Discovery Proxy
---------------------------------------------------

"  This scenario is a sub-case from the previous one.  The IPv6 node
   will never be on the link where the ND messages are proxied.  This is
   case with IKEv2 [RFC4306] when a node needs an IP address in the
   network protected by a security gateway and this latest assigns it
   dynamically using Configuration Payload during IKEv2 exchanges.  The
   security gateway will have to proxy ND messages to be able to
   intercept messages, sent to the node, to tunnel them to this latest.
"

I don't really agree with the statement that this scenario is a subcase 
of the previous one. I understand the scenario as follows: a VPN GW  
assigns to multiple MNs IPv6 addresses from an aggregated prefix. 

I think the scenario describes a bad deployment practice that we 
shouldn't be concerned about. The prefix shouldn't be advertized on a 
link inside the VPN GW's network otherwise this is a multilink subnet.

2.3.  Bridge-like ND proxies
----------------------------

"  Where proxies exist between two segments, messages may be sent by the
   proxy on the far link, in order to gain or pass on Neighbor
   information.  [...]
"

This is obscure. How about: 

The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
method by which multiple link layer segments are bridged into a single 
segment and specifies the IP-layer support that enables bridging under 
these circumstances.

"
                  [...] The proxy in this case forwards messages while
   modifying their source and destination MAC addresses, and rewrites
   their Link-Layer Address Options solicited and override flags.  This
   is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389].
"

I think a coma is missing after "Options".

"
[...]
   ND Proxy resends messages containing their original address, even
   after modification [RFC4389].  Figure 2 describes packet formats for
   proxy Neighbor solicitation and advertisement as specified by the
   specification.
"

s/ND Proxy/An ND proxy

"
[...]
   Once again, these messages may not be signed with a CGA signature by
   the re-advertisor, because it does not own the source address.
"

"re-advertisor" is coming out of the blue here. Someone not familiar 
with ND and ND proxies might miss the point... Can we use a better 
term, or define "re-advertisor".

"
   Additionally, multicast Authorization Delegation Discovery ICMPv6
   messages need to be exchanged for bridge-like ND proxies to prove
   their authority to forward. [...]"

I suggest to remove "multicast" and "ICMPv6" as it's details ortoghonal 
to the issue at stake here. Also, the authority is to act as a router 
for one or more prefix(es) rather than "forward". 

"
                             [...]   Unless the proxy receives explicit
   authority to act as a router, or the router knows of its presence, no
   authorization may be made.  This explicit authorization requirement
   may be at odds with zero configuration goal of ND proxying [RFC4389].
"

s/with zero/with the/

3.  Proxy ND and Mobility
-------------------------

Why do we have this section at all? It seems to be overlapping with the 
2.x section and probably should be merged with those.

4.1.  CGA signatures and Proxy Neighbor Discovery
-------------------------------------------------

"
   Where a proxy replaces the message source with its own CGA, the
   existing CGA option and RSA signature option need to be replaced with
   the proxy's.  Such a message will validate using SEND, except that
   the Target Address field will not match the IPv6 Source Address in
   Neighbor Advertisements [RFC3971].
"

Suggest reword into: When a proxy replaces the message source IPv6 
address with its own CGA, as per SEND specification the existing CGA 
option and RSA signature option would need to be replaced with the 
proxy ones.  Such a message would be valid according to the SEND 
specification, weren't the Target Address and the source IPv6 address 
of the Neighbor Advertisement different [RFC3971].

"
   Additional authorization information may be needed to prove that the
   proxy is indeed allowed to advertise for the target address, as is
   described in Section 5.
"

Isn't this already going to far into solution space? 

We haven't spelled yet what are our solution requirements (ala RFC3756) 
which is clearly part of the problem statement yet we're coming up with 
the need for an additional authorization information...

4.2. "Non-CGA signatures and Proxy Neighbor Discovery"
------------------------------------------------------

The term "Non-CGA signatures" is not the best IMHO. Do you want to 
say "Message not protected with the CGA option"?

"  Where a proxy retains the original source address in a proxied
   message, existing SEND-CGA checks will fail, since fields within the
   message will be changed.  In order to achieve secured proxy Neighbor
   discovery in this case, new signature authentication mechanisms may
   be needed for SEND.
"

Suggest to reword "new signature authentication mechanisms may be needed 
for SEND" into "extended authorization mechanisms will be required". 

But again, aren't we entering solution space. What are the solution 
requirement?

"  SEND provides interfaces for extension of SEND to non-CGA based
   authorization.  Messages are available for Authorization Delegation
   Discovery, which is able to carry arbitrary PKIX/X.509 certificates
   [RFC5280].
"

s/interfaces/mechanisms/

"  There is no specification though of keying information option formats
   analogous to the SEND CGA Option [RFC3971].  The existing option
   allows a host to verify message integrity by specifying a key and
   algorithm for digital signature, without providing authorization for
   functions other than CGA ownership.
"

s/no specification though/however no specification/

s/for functions other/via other mechanism/
 
Hope that is helpful.

--julien
-- 
--julien
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 27 Dec 2008 18:55:37 +0100

Problem with [email-masked] address email.

---------- Forwarded message ----------
From: Jean-Michel Combes <[email-masked]>
Date: 2008/12/27
Subject: Re: Review of draft-ietf-csi-sndp-prob-00
To: Julien Laganier <[email-masked]>
Cc : [email-masked], [email-masked]

Hi,

At first sorry for the late reply and thanks for the review.

> I have reviewed draft-ietf-csi-sndp-prob-00. These are my comments:

Do you speak about:
(1) all the MAGs must have the same LLA?
(2) all the MAGs must advertize the same HNP for a dedicated MN?

(1) is described in section 6.
(2) this is more or less the Bridge-like ND Proxy scenario

Did I miss something?

> should be merged with it.

Yes. I agree. I will try to merge this section in the previous previous.

> there can be the explanation why the current SEND isn't sufficient for

I must admit I don't support such a idea: I would prefer to have a
more general document covering all potential scenarios than a document
only describing 2-3 scenarios like RFC 3756 did.

> of the current document, which belongs to solution space IMHO.

This is just a description of potential approaches and I think we have
to keep it because AFAIK there is no "Solution Space" document today.

> Detailed Review:

"2. Scenarios

  This section describes the different scenarios where the interaction
  between SEND and ND-Proxy raises issues.

  When moving in the Internet, the aim of IPv6 mobility is to allow a
  device continued packet delivery, whether present on its home network
  or not.  The following text is focused on Mobile IPv6 but the issue
  is the same with Mobile IPv6 based protocols (e.g.  NEMO, HMIPv6)."

"Issue" is linked to the text in section 2. But I can modify the text.

NEW TEXT:
"When moving in the Internet, the aim of IPv6 mobility is to allow a
 device continued packet delivery, whether present on its home network
 or not.  The following text is focused on Mobile IPv6 but the issue raised
 by the interaction between SEND and ND-Proxy is the same with Mobile
 IPv6 based protocols (e.g.  NEMO, HMIPv6)."

OLD TEXT:
"  When moving in the Internet, the aim of IPv6 mobility is to allow a
  device continued packet delivery, whether present on its home network
  or not.  The following text is focused on Mobile IPv6 but the issue
  is the same with Mobile IPv6 based protocols (e.g.  NEMO, HMIPv6)."

Is it better?

> notion of home link per se and thus does not need a ND proxy function.

The MAP is a MIPv6-HA and so, AFAIK, needs to proxy ND messages for
correspondents on the link from where the RCoA is derived.

> this document is not a problem statement for a mobility protocol.

No no: issue is the interaction between SEND and ND-Proxy :)

> unreachable at the link layer recorded in the NCE.

OK. Thanks.

> 2.2.  IPv6 Fixed Nodes and Neighbor Discovery Proxy

Agree and I understand your feeling.
But AFAIK the standard today (i.e. RFC 4306) is multilink subnet based
and the "IKEv2 IPv6 address assignment mechanism" document (i.e.
draft-ietf-ipsecme-ikev2-ipv6-config) is still under draft status.
So the question in fact is: do we have to do the analysis on the
standard or the draft?
Feedbacks are welcome.

> 2.3.  Bridge-like ND proxies

OK. Thanks.

> I think a coma is missing after "Options".

NEW TEXT:
"The proxy in this case forwards messages, while
  modifying their source and destination MAC addresses and rewrites
  their Link-Layer Address Options, solicited and override flags.  This
  is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389]."

OLD TEXT:
"The proxy in this case forwards messages while
  modifying their source and destination MAC addresses, and rewrites
  their Link-Layer Address Options solicited and override flags.  This
  is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389]."

>   proxy Neighbor solicitation and advertisement as specified by the

OK. Thanks

> term, or define "re-advertisor".

Agree.

NEW TEXT:
"Once again, these messages may not be signed with a CGA signature by
 the Proxy, because it does not own the source address."

OLD TEXT:
"Once again, these messages may not be signed with a CGA signature by
 the re-advertisor, because it does not own the source address."

> for one or more prefix(es) rather than "forward".

In fact, maybe, we should remove this text because this is too
strongly linked to the solution space ... your opinion?

>   may be at odds with zero configuration goal of ND proxying [RFC4389].

OK. But I have the same feeling that the previous comment: this text
is too strongly linked to the solution space maybe.

> 3.  Proxy ND and Mobility

OK.

> 4.1.  CGA signatures and Proxy Neighbor Discovery

OK. Thanks.

> the need for an additional authorization information...

There is a "may be needed" to let open all potential solutions: this
is not a "must" :)

> 4.2. "Non-CGA signatures and Proxy Neighbor Discovery"

That means "Signatures not based on CGA security material" (e.g.
security material from certs).

> for SEND" into "extended authorization mechanisms will be required".

OK.

> But again, aren't we entering solution space. What are the solution

IMHO, there are no new requirements. We have to keep the same security
level as in SEND but if the standardized solution will not be able to
keep it,IMHO, this is in the solution document that security
limitations should be described.

>   Discovery, which is able to carry arbitrary PKIX/X.509 certificates

OK. Thanks.

> s/for functions other/via other mechanism/

OK. Thanks.

> Hope that is helpful.

Sure :)
Thanks again.

Best regards and happy new year.

JMC.