Subject: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send

From: Alberto García <[email-masked]>
Date: Thu, 4 Mar 2010 12:30:41 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre
de
|  Jari Arkko
|  Enviado el: viernes, 11 de diciembre de 2009 6:37
|  Para: Tony Cheneau
|  CC: [email-masked]; [email-masked]
|  Asunto: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  
|  Tony,
|  
|  > The padding field is exactly defined this way in RFC 3971 (although a
|  > Pad Length field was present on the -04 version of the SEND draft). I
|  > think the draft-ietf-csi-proxy-send-01 document only reuses the format
|  > of the badly defined RSA Signature Option.
|  
|  Ah, OK.
|  
|  > If RFC 3971 was to be updated, I agree that a padding length field
|  > should be defined somewhere in the RSA (or XXX) Signature Option. Was
|  > there a rational behind its removal during the RFC 3971
|  > standardisation process ?
|  
|  I can't recall. Maybe this is one of the bugs that we need to fix. Or
|  perhaps there is a way to determine the lengths but neither of us can't
|  just see it right now. In any case, it should be clearly specified in
|  3971bis and the proxy-send drafts.

The length of the Digital Signature can be obtained from parsing the PKCS#1
v1.5 signature itself, which is coded in ASN.1 BER. 
Therefore, I have changed in draft-ietf-csi-proxy-send-02 the statement
saying:

"The length of the
      	Digital Signature field is determined by the length of the RSA
      	Signature option minus the length of the other fields (including
      	the variable length Pad field.)

by
"The length of the Digital Signature field is determined by the ASN.1 BER
coding of the PKCS#1 v1.5 signature."

Then, I would still say that 
"The length of the padding field is determined by the length of the Proxy
Signature Option minus the length of the other fields."

Do you think this is correct?

Regards,
Alberto

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

---

From: Alberto García <[email-masked]>
Date: Thu, 4 Mar 2010 12:30:41 +0100

Hi Jari,

The changes commented in the rest of the email refer to
draft-ietf-csi-proxy-send-02.

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre
de
|  Jari Arkko
|  Enviado el: jueves, 10 de diciembre de 2009 16:05
|  Para: [email-masked]; [email-masked]
|  Asunto: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  
|  I have reviewed this draft.
|  
|  In general, I'm quite happy with the approach it takes with respect to
|  authorizing proxies with an explicit authorization certificate. I think
|  it is a good and sufficient approach.
|  
|  I do have a number of other technical issues, however. My biggest issue
|  is that this specification could do a much better job with respect to
|  backwards compatibility and mixed nd/send/proxy environments.

We have changed this section to better address compatibility for all these
cases. 

|  
|  > It is not possible to apply the current SEND specification to protect
|  > the NA message issued by the HA.
|  
|  Strictly speaking this is not entirely correct. You only cannot support
|  certain modes of operation. For instance, the virtual home link
|  operation is trivially compatible with SEND. Also, since the home agent
|  and the mobile node need to agree on a home address, the actual owner of
|  the IP address (and corresponding private keys) could be either the home
|  agent or the mobile node. Current SEND specifications do not support
|  signatures for the same address coming from either the home agent or the
|  mobile node. But it would be possible for the home agent to sign the NA
|  messages, if it was the original owner of the home address. I'm not sure
|  any of this has much practical significance, but I wanted to bring this
|  up anyway, because the statements in the draft should be correct.

Agreed.
We have removed this part, since (as you comment below), this is problem
statement, and should be just in the problem statement document.

|  
|  > The approach described above and the current SEND specification are
|  > incompatible since:
|  >
|  >   Sharing the same link-local address on different MAGs would
|  >   require all MAGs of a PMIPv6 domain to construct the CGA and the
|  >   RSA Signature option with the same public-private key pair, which
|  >   is not acceptable from a security point of view.
|  >
|  
|  AFAIK there is no requirement that routers construct CGAs.

Yes, routers do not need to use CGAs, but need to be certified. We correct
this part.

Besides, there is an issue here regarding to RFC3971. From my understanding
of what it is written in RFC3971, a router can act a proxy with the current
specification. In the certificate allowing a router to operate as such, it
is not clear that the 'subject' should be an IP address (moreover in the
example of section 6.3.1, it is a FQDN), and it is not specified to check
that the IP address of the subject is the same as the source address, etc.
of the messages to validate with that public key. So I understand that the
router could use its public key to sign messages coming from ANY address. 
>From my point of view, this allows an attacker controlling the router to
impersonate any other host, and doing this at the SEND security level. I
think this should not be the default behavior, but if a proxy is required,
this mode of operation should be authorized explicitly (as is proposed in
the Certificate Profile and Secure Proxy ND).

Assuming routers are not proxies, if the PMIPv6 is to be solved without
Secure Proxy ND, each MAG should be configured with 1 certificate per
possible link local address required by a MN. When using the Secure Proxy ND
mechanism, only one certificate is required for this purpose, so the
deployment is made easier. Therefore, the use of the proxy is just an
optimization.

Do you think this analysis is correct?

|  
|  > 4. Application Scenarios
|  
|  There seemed to be some duplication with respect to
|  draft-ietf-csi-sndp-prob.

Duplication has been removed (at least partially). Now 'Application
scenarios' has moved after the specification of the mechanism, and now the
approach is to show how the Secure Proxy ND is deployed for the application
scenarios considered.

|  
|  > When any of these
|  > messages is received with a valid Proxy Signature option, it is
|  > considered as secure even if it doesn't contain a CGA option.
|  >
|  
|  I think there needs to be a difference with respect to whether the
|  original message had a CGA option or not. The receiver on the other side
|  needs to know this in order to decide whether to override an cache entry
|  or not, in a manner similar to what RFC 3971 already does.

Well, I interpret that the sentence originally referred to the fact that
when a node receives a message including the PSO option, this option makes
the message to be 'as secure' as if a CGA option + RSA option is received.
In any case, it has been removed.
Your comment about the original message having security or not, I think it
is now covered in the 'Compatibility' section. 

|  
|  >       This field starts after the Key Hash field.  The length of the
|  >       Digital Signature field is determined by the length of the RSA
|  >       Signature option minus the length of the other fields (including
|  >       the variable length Pad field.)
|  >
|  >    Padding
|  >
|  >       This variable-length field contains padding, as many bytes long
as
|  >       remain after the end of the signature.
|  >
|  
|  I don't understand how to calculate the length of the Signature field,
|  because the padding field's length is not described anywhere.

I follow up this topic in another email.

|  
|  > The modifications described in the following section applies when a
|  > SEND message contains the Proxy Signature option (PSO), i.e. the
|  > message was sent by a Secure Proxy ND.
|  >
|  
|  This does not seem like the only required modification. I would also
|  like to see what a host on the other end should do if it has a cache
|  entry that came from a PSO signed SEND message, and the host now
|  receives a classic 4861 or 3971 message.

This is now discussed in the 'Compatibility' section. 

|  
|  > When any of these
|  > messages is received with a valid Proxy Signature option, it is
|  > considered as secure even if it doesn't contain a CGA option.
|  >
|  ...
|  > A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST
|  > contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
|  > RSA Signature options.
|  >
|  
|  I read the first statement as the CGA being optional, and now you are
|  saying its a MUST NOT. Maybe the first statement needs to be made
clearer.
|  
|  Nevertheless, wouldn't it be good if the proxy didn't actually remove
|  any information from the messages? First of all, its a little bit tricky
|  to ensure that a proxy is capable of removing all SEND options that
|  might be defined over time. Secondly, it seems like the wrong thing to
|  do conceptually. You want to inform the other side that this message was
|  proxied, but you may also want to know that the message was initially
|  signed. This can be important, for instance, to decide whether to
|  override a cache entry. I would not override a secure entry based on a
|  securely proxied insecure message, for instance.

Not removing previous information is problematic. RFC3971 hosts (i.e. hosts
not aware of this Secure Proxy ND specification) would process the packet
with a RSA signature... to see that the message information (for example,
the link layer address contained) has changed because of the proxy function,
and the signature is not valid. The message would be discarded (instead of
being considered as unsecure).
Secondly, not all proxied messages are translations of SEND messages, but in
some cases (for example the MIPv6 and the PMIPv6 case) the ND messages are
synthesized from the scratch by the proxy (without receiving a SEND message
from the proxied host). So I assume the decision of whether a cache entry
must be overridden or not must depend just on the proxy sending or not PSO
options, requiring appropriate configuration in the proxy. More on this on
the 'compatibility' section of the v02 of the draft.

What do you think? 

|  
|  > 7. Backward Compatibility with legacy SEND nodes
|  The specification does not explain how a receiver treats different
|  combinations of existing cache entries involving a ND, SEND, or proxy
|  SEND source and a new message from a ND/SEND/proxy SEND source.

Hope this has been clarified

|  
|  Finally, I'm not sure the draft does a good job of explaining which
|  scenarios it covers from sndp-prob and which not. FWIW, I think this
|  draft is all we need and we do NOT need to cover all possible scenarios
|  from sndp-prob. But the readers would still like to understand the
|  situation.

I think it should be clearer with the new structure of the document.

Regards,
Alberto
|  
|  Jari
|

---

From: Alberto García <[email-masked]>
Date: Thu, 4 Mar 2010 12:30:41 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre
de
|  Laganier, Julien
|  Enviado el: martes, 24 de noviembre de 2009 17:46
|  Para: Tony Cheneau
|  CC: [email-masked]; [email-masked]
|  Asunto: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01
|  
|  Hi Tony,
|  
|  I had overlooked the proxy ND siphoning off traffic exchanged between two
on-
|  link link-local addresses. I agree that this is a difference with the
compromised
|  router threat and should be acknowledged in the document. How about the
|  following?
|  
|     Thanks to the authorization certificate it is provisioned with, a
proxy ND
|     is authorized to issue ND signaling on behalf of nodes on the subnet.
|  
|     Thus, a compromised proxy is able, like a compromised router, to
siphon off
|     traffic from the host, or mount a man-in-the-middle attack. However,
when
|     two on-link hosts communicate using their respective link-local
addresses,
|     the threats involved with a compromised router and a compromised proxy
ND
|     differs because the router is not able to siphon off traffic exchanged
|     between the hosts or mount a man-in-the-middle attack, while the proxy
ND
|     can.
|  
|     As for SEND which does not protect against attacks involved with the
|  compromise
|     of a router, as described in Sections 9.2.4 of [RFC3971], Secure Proxy
ND
|  Support
|     for SEND does not protect against similar attacks involved with the
|     compromise of the proxy ND. However, the additional threat of
siphoning off or
|     mounting a man-in-the-middle attack between two link-local addresses
is
|  countered
|     by having SEND nodes receiving both unproxied and proxied messages
give
|  priority to
|     unproxied ones.  Here, the "unproxied" messages are those that contain
a valid
|  signature
|     option as specified per the SEND specification [RFC3971], and
"proxied"
|     messages are those that contain a valid proxy signature option (PSO)
as
|     specified in this document.

I don't think the solution is just prefer 'unproxied' information over
'proxied' information. 
For example, I think this would defeat MIPv6 operation (see RFC3775, section
10.4.1): when a node moves away from the home link, the HA multicasts a NA
message, with override flag set to 1 "indicating that the Advertisement
SHOULD override any existing Neighbor Cache entry at any node receiving it."
In this case, the proxied SHOULD override the unproxied message. 
To support this, an explicit mention to this behavior has been included in
the 'Processing rules for receivers' section of version 02 of the draft.

What do you think?

Regards,
Alberto

|  
|  As to specifying that the proxy ND is always authorized to proxy for
addresses in
|  the fe80::/64 prefix vs. inclusion in the certificate of either a list of
node's link
|  local addresses that the proxy ND is authorized to proxy, or of the whole
|  fe80::/64 prefix, I have no strong opinion and would like to ask the WG
|  participant what is their preference there?
|  
|  --julien
|  
|  > -----Original Message-----
|  > From: [email-masked] [mailto:[email-masked]] On
|  > Behalf Of Tony Cheneau
|  > Sent: Saturday, November 21, 2009 1:53 AM
|  > To: Laganier, Julien
|  > Cc: [email-masked]; [email-masked]
|  > Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01
|  >
|  > Hi Julien
|  >
|  > On Fri, 20 Nov 2009, Laganier, Julien wrote:
|  >
|  > > Tony,
|  > >
|  > > If a router is compromised, it can send a RA containing a PIO with
|  > the L bit set to zero, and thus two hosts on the link trying to
|  > communicate will sends their packets to the router and will not attempt
|  > to resolve each others' address. Doing so, it can mount a MiTM attack
|  > of siphon off packets sent by a host. This is acknowledged in section
|  > 4.2.1. of RFC 3756.
|  > Indeed, I forgot this L flag. You're right.
|  >
|  >
|  > > Regarding the fe80::/64 prefix, it does not need to be advertized by
|  > the router or proxy. It should be assumed that a ND proxy is always
|  > authorized to proxy signaling for the fe80::/64 prefix. That does not
|  > need to be signaled in the certificate, it has to be written down in
|  > the draft however :)
|  > This is a good way to go (other way around seems to add the fe80::/64
|  > prefix to
|  > the Secure Proxy ND's certificate). However, can you add a security
|  > consideration specific to this new "rule" ? I see a security issue
here.
|  >
|  > From RFC 4861, section 4.6.2 (the Prefix Information Option):
|  > "A router SHOULD NOT send a prefix option for the link-local prefix and
|  > a host
|  > SHOULD ignore such a prefix option."
|  >
|  > Meaning that the attack in 4.2.1 of RFC 3756 "SHOULD NOT" work on two
|  > nodes
|  > communicating directly using their link-local addresses (as the PIOs
|  > sent by
|  > the router will more likely be ignored).
|  > Here, the Secure Proxy ND seems to be able to siphon off the
|  > communication of
|  > the same two nodes using their link-local addresses (as it is always
|  > authorized
|  > to proxy signaling for the fe80::/64 prefix).
|  >
|  > Maybe I am (again) missing something here.
|  >
|  >
|  > Regards,
|  >  	Tony
|  > _______________________________________________
|  > CGA-EXT mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/cga-ext
|  _______________________________________________
|  CGA-EXT mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/cga-ext

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 4 Mar 2010 08:12:21 -0800

Jari,

> [...]
> 
> >
> >   Sharing the same link-local address on different MAGs would
> >   require all MAGs of a PMIPv6 domain to construct the CGA and the
> >   RSA Signature option with the same public-private key pair, which
> >   is not acceptable from a security point of view.
> >
> 
> AFAIK there is no requirement that routers construct CGAs.

If the router does not construct a CGA it will not be able to send secure Neighbor Advertisement messages for its own address, as per RFC3971: 

   Neighbor Solicitation and Advertisement messages without the CGA
   option MUST be treated as unsecured

Since the router does need to send Neighbor Advertisements for its own address whenever a host on the link initiates Neighbor Unreachability Detection, it seems to me that there is indeed a requirement that a router constructs a CGA as per RFC3971. I am missing something?

--julien

---

From: Tony Cheneau <[email-masked]>
Date: Sun, 21 Mar 2010 18:04:16 +0100 (CET)

Hello Alberto,

I agree with your new text.

However, I can not help but think that the PadLen field will be
requiered later on, when other signature algorithms will be used (where
the signature may not encode its own lenght). 
I think the WG should have a discussion on re-introducing or justifying
the lack of PadLen field. Because, if you choose not to introduce it in
this spec, there might be two specs to fix later on.

Also, I spotted a small typo in the Reserved field:
"A 11-bit field reserved" => "A 16-bit field reserved"

Regards,
 	Tony

---

From: Alberto García <[email-masked]>
Date: Mon, 22 Mar 2010 10:59:17 +0100

|  -----Mensaje original-----
|  De: Tony Cheneau [mailto:[email-masked]]
|  Enviado el: domingo, 21 de marzo de 2010 18:04
|  Para: Alberto García
|  CC: 'Jari Arkko'; [email-masked];
[email-masked]
|  Asunto: RE: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  
|  Hello Alberto,
|  
|  I agree with your new text.

Thanks, Tony
 
|  However, I can not help but think that the PadLen field will be
|  requiered later on, when other signature algorithms will be used (where
|  the signature may not encode its own lenght).
|  I think the WG should have a discussion on re-introducing or justifying
|  the lack of PadLen field. Because, if you choose not to introduce it in
|  this spec, there might be two specs to fix later on.

It is ok for me to discuss this point, but my opinion is that, in case there
is an agreement to use other signature algorithms, changes will be so
relevant that at the end this spec would need to be updated, regardless the
introduction of a PadLen field. 

|  
|  Also, I spotted a small typo in the Reserved field:
|  "A 11-bit field reserved" => "A 16-bit field reserved"

Thanks, I correct it in a new version just being issued

Regards,
alberto
|  
|  Regards,
|   	Tony
|  
|  On Thu, 4 Mar 2010, Alberto García wrote:
|  
|  > Hi
|  >
|  > |  -----Mensaje original-----
|  > |  De: [email-masked] [mailto:[email-masked]] En
nombre
|  > de
|  > |  Jari Arkko
|  > |  Enviado el: viernes, 11 de diciembre de 2009 6:37
|  > |  Para: Tony Cheneau
|  > |  CC: [email-masked]; [email-masked]
|  > |  Asunto: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  > |
|  > |  Tony,
|  > |
|  > |  > The padding field is exactly defined this way in RFC 3971
(although a
|  > |  > Pad Length field was present on the -04 version of the SEND
draft). I
|  > |  > think the draft-ietf-csi-proxy-send-01 document only reuses the
format
|  > |  > of the badly defined RSA Signature Option.
|  > |
|  > |  Ah, OK.
|  > |
|  > |  > If RFC 3971 was to be updated, I agree that a padding length field
|  > |  > should be defined somewhere in the RSA (or XXX) Signature Option.
Was
|  > |  > there a rational behind its removal during the RFC 3971
|  > |  > standardisation process ?
|  > |
|  > |  I can't recall. Maybe this is one of the bugs that we need to fix.
Or
|  > |  perhaps there is a way to determine the lengths but neither of us
can't
|  > |  just see it right now. In any case, it should be clearly specified
in
|  > |  3971bis and the proxy-send drafts.
|  >
|  > The length of the Digital Signature can be obtained from parsing the
PKCS#1
|  > v1.5 signature itself, which is coded in ASN.1 BER.
|  > Therefore, I have changed in draft-ietf-csi-proxy-send-02 the statement
|  > saying:
|  >
|  > "The length of the
|  >      	Digital Signature field is determined by the length of the
RSA
|  >      	Signature option minus the length of the other fields
(including
|  >      	the variable length Pad field.)
|  >
|  > by
|  > "The length of the Digital Signature field is determined by the ASN.1
BER
|  > coding of the PKCS#1 v1.5 signature."
|  >
|  > Then, I would still say that
|  > "The length of the padding field is determined by the length of the
Proxy
|  > Signature Option minus the length of the other fields."
|  >
|  > Do you think this is correct?
|  >
|  > Regards,
|  > Alberto
|  >
|  > |
|  > |  Jari
|  > |
|  > |  _______________________________________________
|  > |  CGA-EXT mailing list
|  > |  [email-masked]
|  > |  https://www.ietf.org/mailman/listinfo/cga-ext
|  >
|  >

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Mar 2010 18:28:20 -0700

> We have changed this section to better address compatibility for all these

Great!

> statement, and should be just in the problem statement document.

OK.

> Yes, routers do not need to use CGAs, but need to be certified. We correct

OK

> router could use its public key to sign messages coming from ANY address. 

Since it is a router, presumably it is allowed to advertisize anything 
it wants in RAs, including that all prefixes are off-link. This would 
allow it work as a proxy.

> Do you think this analysis is correct?

I think so.

> approach is to show how the Secure Proxy ND is deployed for the application

OK, good.

> is now covered in the 'Compatibility' section. 

OK.

> I follow up this topic in another email.

...

> This is now discussed in the 'Compatibility' section. 

Good.

> being considered as unsecure).

OK. I understand that problem now.

> the 'compatibility' section of the v02 of the draft.

OK. I need to read it...

> I think it should be clearer with the new structure of the document.

Good. Thanks for the hard work on updating the draft.

Jari

---

From: Alberto García <[email-masked]>
Date: Tue, 23 Mar 2010 11:32:05 +0100

Hi,

Thanks for your comments. 
Just one topic to discuss:

|  -----Mensaje original-----
|  De: Jari Arkko [mailto:[email-masked]]
|  Enviado el: martes, 23 de marzo de 2010 2:28
|  Para: Alberto García
|  CC: [email-masked]; [email-masked]
|  Asunto: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  

[...]
  
|  > |
|  > |  > The approach described above and the current SEND specification
are
|  > |  > incompatible since:
|  > |  >
|  > |  >   Sharing the same link-local address on different MAGs would
|  > |  >   require all MAGs of a PMIPv6 domain to construct the CGA and the
|  > |  >   RSA Signature option with the same public-private key pair,
which
|  > |  >   is not acceptable from a security point of view.
|  > |  >
|  > |
|  > |  AFAIK there is no requirement that routers construct CGAs.
|  >
|  > Yes, routers do not need to use CGAs, but need to be certified. We
correct
|  > this part.
|  >
|  
|  OK

Well, actually I've changed my mind about this. 
First of all, I must say that the way routers sign ND messages is not
crystal clear in the SEND specification. 
As Julien pointed out in a previous email, RFC3971 states that the CGA
option MUST be present in all NS and NA. Then, I assume that routers must
have a CGA, and NS and NA must sign the NS and NA messages with the key
associated to the CGA. 
There are other places in the specification that suggest that routers should
use a CGA, for example: "By default, a SEND-enabled node SHOULD use only
CGAs for its own addresses." (RFC3971 section 7.1, addressing).

However, SEND specification present some 'holes' which could make the
previous assertions not to hold (at least, as I understand the text):
- A router could issue a NS or NA containing a CGA, but sign the message
with a different key (with the key authorized by a certificate derived from
a trust anchor). Note that the RSA option has a field in which a 'pointer'
to the key used, the Key Hash, is included. There is no rule stating that
the receiver should check that Key Hash of the RSA option should point to
the key of the CGA contained in the message (in fact, there is section 5.2.3
saying that the binding requirements between the RSA option and the type of
key used should be configurable per ND message type - unfortunately, it does
not set default values for this, which would be clarifying). However, I
interpret that the statement saying that the CGA must be present always
means that the key used should be the CGA, even for the router. This
behavior also allows the router using two different keys, one for signing RA
messages, and other for NA/NS (for example NUD), which prevents excessive
exposing of the certified key. 
- Communication on behalf of a proxied router (as in the PMIPv6 case) could
proceed without NS or NA exchange, since reachability (NUD) can rely on
hints from upper-layer protocols. The proxy (router) could issue a RA
message, with the address of the proxied router, signed with a key different
from a CGA but the key authorized by a valid certification path. This RA can
include the link-layer address of the proxy router. Then, upper-layer
information could maintain reachability, without requiring NS and NA
exchange. Since CGA is not required, in this scenario a router could perform
as a proxy for other router. Of course, I think this is much more a corner
case than a common situation; this is just to show that there are some cases
in which CGA would not be required.

Overall, I don't think we can assume that a router could behave as a proxy
on behalf of other addresses different than its own address, even in the
PMIPv6 case. 
Consequently to this, the text in 03 for the PMIPv6 case now presents it as
a solution, more than a way of making things easier.

What do you think?

Regards,
Alberto

|  
|  > Besides, there is an issue here regarding to RFC3971. From my
understanding
|  > of what it is written in RFC3971, a router can act a proxy with the
current
|  > specification. In the certificate allowing a router to operate as such,
it
|  > is not clear that the 'subject' should be an IP address (moreover in
the
|  > example of section 6.3.1, it is a FQDN), and it is not specified to
check
|  > that the IP address of the subject is the same as the source address,
etc.
|  > of the messages to validate with that public key. So I understand that
the
|  > router could use its public key to sign messages coming from ANY
address.
|  >
|  
|  Since it is a router, presumably it is allowed to advertisize anything
|  it wants in RAs, including that all prefixes are off-link. This would
|  allow it work as a proxy.
|  
|  > >From my point of view, this allows an attacker controlling the router
to
|  > impersonate any other host, and doing this at the SEND security level.
I
|  > think this should not be the default behavior, but if a proxy is
required,
|  > this mode of operation should be authorized explicitly (as is proposed
in
|  > the Certificate Profile and Secure Proxy ND).
|  >
|  > Assuming routers are not proxies, if the PMIPv6 is to be solved without
|  > Secure Proxy ND, each MAG should be configured with 1 certificate per
|  > possible link local address required by a MN. When using the Secure
Proxy ND
|  > mechanism, only one certificate is required for this purpose, so the
|  > deployment is made easier. Therefore, the use of the proxy is just an
|  > optimization.
|  >
|  > Do you think this analysis is correct?
|  >
|  
|  I think so.
|  
|  >