Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt

Jari,

Thanks for your comments. Comments inline..

>
> I have read draft-ietf-pana-ipsec-00.txt, and I have a few
> comments. Apologies if this has been discussed before, I was
> unable to participate the WG session due to other commitments.
>
> Here are the comments:
>
> - Section 3.0, bullet 3. This document appears to assume
>    that the IPv6 node has a single address. What about RFC 3041
>    etc?
>
This  is the same problem that we had in Mobile IPv6 i guess.
PANA supports device-id AVP which can be used to communicate
the RFC3041 address to PAA. As we are not solving the address
ownership problem here, this should be okay i guess. See more
on this below.

> - Section 4.0, Session ID. I'm glad that the document uses
>    a session ID -- those are indeed needed, as it is possible
>    that more than one EAP session was run, and we need to know
>    where to refer to.
>
>    However, I still have one problem with this. The problem
>    is that it is not enough to use the Session ID as a part
>    of the IKE pre-shared secret. It is also necessary to
>    carry the session id information in IKE so that the
>    two peers know which key to use.
>
>    How do you intend to do that? The usual IKE payloads don't
>    appear to carry this information, though it might be that
>    ID_KEY_ID identity type might be usable. (The IKEv1 documents
>    appear to imply that this type is normally used for vendor
>    specific identification.) Or perhaps a new IKE identity type
>    is needed.
>
I have checked with a few implementors and it is not that uncommon.
I heard that cisco VPN software uses this. ID_KEY_ID. As i mentioned
else where, ID_KEY_ID is typically used to hide identities in agressive
mode by using opaque blobs. Session Id can be seen as opaque blob.

> - Section 5.0, manual keying comment. It seems inappropriate.
>    The purpose of PANA is to do an auth and then use those keys
>    to protect traffic. If manual keys were used in IPsec, those
>    would not be linked to the authentication, so it does not seem like
>    a valid combination.
>
Okay.

> - Section 5.0, main mode. I think the IP addresses are apparent
>    from the packets themselves, but the session ID would have to
>    be transported (perhaps in the identity payload) to distinguish
>    possibly different EAP runs that you had done before. However,
>    this seems problematic, as IKEv1 pre-shared secret mode does
>    not allow the transport of the identity before the identity
>    needs to be known. Are you relying on IKEv2, or would you have
>    to resort to the use of aggressive mode only?
>
I am planning to use just the aggressive mode in future versions.

> - Section 5.0, aggressive mode. I don't understand what the
>    issue with link-locals is. If the link-local addresses were
>    not unique, how would the client - EP communication succeed
>    in the first place? Anyway, as I said above I think the ID_KEY_ID
>    may be needed just to differentiate EAP runs.
>
This issue was brought up by Francis Dupont. And it is more philosophical
than technical. I guess as it will go away now, it should not be confusing
anymore.

> - Section 6.0, I wish there was some notation to show that the
>    inner and outer addresses are different. They are, right?
>    The text is vague since it only talks about the outer addresses
>    being link-local, but does not say anything about the inner
>    addresses.

Yes. For IPv4, it is even more ambiguous intentionally.
Up until now, in IPv4, PaC's start off with unspecified address and once
the authentication is complete, they configure an address and
thus really had one address. So, outer and inner source address
would be same.

After IETF58 PANA meeting, i think we are not going to use
unspecified address anymore.  This means, both in IPv4 and IPv6
mode, it will always now start off with link-local address and
then acquire a real address /autoconfigure a real address.
So, i will clarify this in future document.

>
> - Section 7.2, ICMP type selectors. I believe this was added
>    to the IPsec documents a couple of months ago. They are not
>    RFCs yet, but neither is PANA, so maybe you could refer to them.
>
Okay.

>    And if you do that, you could use more specific SPD entries,
>    as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its
>    expired, but you can find it here:
>    http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt
>
Thanks.

> - Section 9.0, stealing another PaC's traffic. This is interesting.
>    I believe you are talking about the *inner* addresses in the packets,
>    right?
>
Yes.

>    Note that if the PAA were responsible for inner IP address assignment,
>    this would not be a problem. But I'm not sure how. Perhaps you could
>    use IKEv2 and its address assignment function, then the EC and PAA
>    would communicate via a AAA protocol to get the address. But this
>    needs more thought. Bernard, do you know what 802.11i says about
>    this subject? It seems that its a similar issue in there.
>
Yes, we are having some private discussion on this looking at some
possibilities. Following are possible scenarios. Not yet fully analysed.

1) You can do PANA first, followed by DHCP (pana-dhcp-draft),
     followed by IPsec access control. Thus, when DHCP is used,
     this can be used to solve the address ownership problem.

2) You can do PANA first, followed by IPsec access control
     to protect the router discovery part of SEND.

>    Or is there a need to do some SEND-like address ownership
>    verification? I'm not sure how all the pieces fit together.

Like in 802.11i where there is no mac address ownership, we are
not solving IP address ownership here. But possible in some cases as
i mention above. I think we can at least document them if needed.

>    Is there a PANA document somewhere that describes what the
>    other mechanisms are that you say the PAA can use?
>

I really had SEND in mind when i wrote this. Since then, we have
been thinking of other possibilities.

> Editorial:
>
> - I don't see how the NC-DC-PL-DRL discussion fits section 7.2.
>    Move it elsewhere?

This comment came from Francis. His idea was to describe more from
RFC2461's point of view. I will think about this.

>
> - s/TUNEL/TUNNEL/g
>
Okay.

Thanks
mohan

> --Jari
>
>
>
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www1.ietf.org/mailman/listinfo/pana

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana