Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt

[[e-mail] (Arnaud Ebalard)]

Hi,

Hesham Soliman <[e-mail]> writes:

>>>> "internal API" meaning "implementation dependent feature", i.e. not
>>>> specified in MIPv6 documents.
>>> 
>>> => Yes of course.
>> 
>> ok, but that's just not clearly stated in the document.
>
> => I'm trying to make it clear that the document is not inventing this API
> but inheriting it. In order for anyone to be able to implement this document
> they need to read 3775/6, 4877 and understand the interactions with IPsec.
> If people do that, then they *already* know that an API exists.

No. They know that there is a need for tight interactions between
IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for
internal IKE daemon structures updates. All they get is a pointer to the
old MIGRATE draft in 4877 as a possible hint for solving the second point:

      Such address changes can be implemented, for instance, through an
      API from the Mobile IPv6 implementation to the IPsec
      implementation.  One such API is described in [12].

> For example, did you see any reference of this API in nemo specs?

No, because NEMO does not need to extend it. Does it?

> Any reference in any other MIPv6 specs that are dependent on the specs
> above? 

No, but are there some among those that extend the API?

> There is a reason for that: they all depend on the original MIPv6 specs.

Or they do not have additional needs associated w/ the API.

>>>> I mean: How is the IKE daemon expected to find out which addresses and
>>>> ports to use? Can you take as example a MN w/ multiple interfaces? How
>>>> does it know which ones have been selected by the HA?
>>> 
>>> => Are you still talking about the IKE daemon in the HA? It's responding to
>>> IKE messages from the MN. I don't understand the question.
>> 
>> Sorry for the confusion. I wrote HA while thinking MIPv6 module: the
>> correct last sentence is: How does it know which one has been selected
>> by the MIPv6 module?
>> 
>> 
>>> If you're talking about IKE in the MN, then it's more confusing to me
>>> because it *initiates* the communication.
>> 
>> IKE needs to be modified to guess the right address, that's all I say. In
>> the same fashion as *expected* in 3775/3776 for initial transport mode
>> negotiation. I think you just suppose "the API" also provides that.
>
> => There is no guessing in the MN, it's provided the home address as part of
> the src address selection. If you're talking about running IKE for NAT
> traversal and securing all traffic then it re-uses the SAs for the home
> address.

Sorry, but I fail to understand the whole paragraph. What I say is the
following: when a common Mobile Node negotiates its initial transport
mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs
to perform the IKE negotiation using the CoA. A common IKE
implementation is not expected to do that (SP uses the HoA, which is
not available at that time) and need to be modified to support that. One
possible solution is to have the right address (CoA) provided to the IKE
daemon by the MIPv6 module. Obviously, you are aware of that. Now what
are the exact steps on a DSMIPv6-compliant MN using IKE when it starts
operating in an IPv4-only network? I just reread 6.2.1 and it still
seems unclear to me how the IKE implementation will decide that it
should use a V4ADDR and then which V4ADDR it will use.

Does the IKE implementation take the first v4 address available to do
that? What if it has multiple interfaces with privates IPv4 address?

It is possible I missed some part in the document that explain that
precisely.

>> You will agree that the document adds additonal requirements for that
>> API, w/o making them explicit.
>
> => They are all in the security considerations discussion in great detail.

Some of my comments/questions were about those elements of the security
consideration section. 

> I'm not sure what you're asking us to add. Please send the text that you
> think we need to add to that section.

ok. I will *try* and find some time this WE to provide some text.

>>>> That's what I thought. What's the point in requiring *only* the HA to
>>>> support that? What is the reason not to require that for the MN too?
>>> 
>>> => I believe you were quoting text that refers to updates due to the MN's
>>> address changes. It is required for the HA as the default mechanism. If the
>>> MN supports it then it's fine, if not the MN will need to re-negotiate the
>>> SA. So there is no need to mandate it for the MN.
>> 
>> Let me rephrase it: Why is it a MUST on the HA (i.e. *arguments*) and some
>> kind of 'can' for the MN? How were those levels of support decided? Based
>> on which *technical* arguments?
>
> => Because the ideal scenario is to support this mechanism in order to
> minimise traffic disruption. Therefore, we had to propose this as the
> default for the HA. The mechanism itself is a SHOULD in the IKE spec.
> You need to specify a default common to all MNs. Now, if an MN doesn't
> support it or doesn't care then there is nothing we can do about that. There
> is no point in mandating something when ignoring that mandate makes a
> difference to only one side of the protocol and has no impact on the node it
> communicates with.

It does not seem logical to me. Sorry. It just creates a situation where
client will undergo traffic disruption with a compliant implementation
even if the one on the HA support the feature. 

>>> => Ok, I'm guessing (because you didn't say) that this is related to the API
>>> concern you have. My point on that is that it's a bit too late to worry
>>> about it since it's already out there in implementations.
>> 
>> What can I say: I worked on the API (MIGRATE), made a followup draft
>> correcting problems found during the implementation, implemented support
>> for racoon, UMIP, additions for Linux Kernel and helped strongSwan
>> people during their implementation of my draft.
>
> => Ok, so what are you asking me to do?

I don't know. What about taking a look at the draft [1] and see if the
API can easily be used/extended for some of the needs you have in the
doc. I let you decide.

[1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

>>> => I think that this API was already assumed 5 years ago during the security
>>> rehash of MIPv6. This is not a new assumption in this spec.
>> 
>> From the discussion I had w/ Julien some time ago on the need for that
>> kind of API, I am not that sure. And I don't think we should issue specs
>> with floating assumptions. We cannot expect future implementors were
>> there 5 or 6 years ago reading the list, can we?
>
> => Of course not, but we can expect them to read the specs that we're
> dependent on because they have to do that in order to implement the
> spec.

yes, I agree.

> I personally don't want this API at all in MIPv6 but there is no point in
> discussing this here.

I don't think this would make sense to add the API in MIPv6 either. But
support for IPsec tunnel endpoints update upon movement is required by
3775. Bootstrapping w/ IKE does not work w/o it and updates of internal
IKE structures is also a need. In the end, for things to work smoothly,
it is needed.

> The point is this: What are you asking the WG to add to the spec? Can
> you send text? 

As written previously, I will try and take a look this WE, and then send
some text.

Cheers,

a+
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext