Subject: [nemo] Comments on draft-eddy-nemo-aero-reqs-00.txt

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 03 Jun 2007 20:42:32 +0200

Hi Wesley,

	I've read your draft and I've found it very interesting and clear. I'm
talking from the perspective of a person working on NEMO RO mechanisms,
and sometimes I find myself not knowing which are the most important
metrics/requirements of a practical NEMO RO solution to be deployed in
real scenarios. Thanks for the draft!

	After the reading, I have some comments/questions:

- There are some requirements, such as Req2 (multihoming) that seem to
me more related to the general NEMO solution required for aeronautical
environments than to a NEMO RO particular solution. I agree that a NEMO
RO solution should work when multiple MRs/HAs are used, but IMHO the
multihoming support itself should be provided by multihoming mechanisms,
rather than by the NEMO RO solution (although the RO mechanism should be
compatible to these solutions). I think it would be useful to clarify
that in the text.

- I miss one requirement saying that the NEMO RO solution must be
secure. Req8 says that IPsec must be usable, but I think that's a
different issue (e.g., a particular NEMO RO solution must allow IPsec to
be used while enabling new attacks). Therefore, I'd add a requirement
specifically stating that the NEMO RO solution must be secure, and I'd
describe to which kind of attacks it should be secure and which are the
assumptions about the existing infrastructure (something similar to what
is said in RFC 4225).

- I also miss a requirement about which are the types of MNNs that
should be supported by the NEMO RO solution. From the reading of the
draft, it seems to me that all kinds of MNNs should be supported (i.e.,
LFNs, LMNs and VMNs). This requirement is important, because many
solutions proposed so far only deal with the optimisation of certain
MNNs/configurations (e.g., nested networks, VMNs, etc).

	Kind Regards,

	Carlos

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 5 Jun 2007 11:30:16 -0400

> real scenarios. Thanks for the draft!

Excellent, I'm glad it is helpful.

> compatible to these solutions). I think it would be useful to clarify

Yes, I think you're right.  The text should be more clear here in saying
that providing multihoming is not itself a requirement, but "MUST NOT
preclude multihoming" *is* a requirement.  We'll try to fix this.

> assumptions about the existing infrastructure (something similar to what

I'm not quite sure about this "must be secure" is rather vague and could
be too loose in that it permits sort-of homebrew schemes that look
secure at first, but after a few years turn out to not be.  I prefer to
require the securability to be vai IPsec, since it is well understood and
maintained by the IETF, whereas other ways to "secure" RO schemes may not
be.

> MNNs/configurations (e.g., nested networks, VMNs, etc).

At least LFNs and LMNs MUST be supported by the RO solution in our case,
and it would be very desirable for deployment purposes to support VMNs as
well (SHOULD?).

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 05 Jun 2007 18:17:02 +0200

Hi Wesley,

> maintained by the IETF, whereas other ways to "secure" RO schemes may not

	I think I'm not explained myself clearly. I'm referring to the security
of the RO mechanism itself. As far as I understand, one issue is to
allow end to end traffic to be secured by using IPsec and another issue
is how secure the NEMO RO solution (security was the key issue in the RO
solution adopted by MIPv6, and this security is not provided by IPsec).
Do you see my point?

> and it would be very desirable for deployment purposes to support VMNs as

	OK.

	Kind Regards,

	Carlos

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 7 Jun 2007 14:10:37 -0400

> solution adopted by MIPv6, and this security is not provided by IPsec).

I think I understood/understand your question, but I'm still of the
opinion that IPsec should be relied on.  I don't feel incredibly
strongly about this, and could be convinced otherwise though.

I understand that the MIPv6 basic RO security isn't IPsec based, but I
don't see this as a good reason not to require the NEMO RO to be
securable through IPsec.  The MIPv6 RO security wasn't built on IPsec
because it was felt that the needed PKI structure didn't exist.  With
recent work like BTNS, I believe this concern could be revisited.  RO
security based on BTNS seems reasonable to me (for both MIPv6 and NEMO),
since it could ensure that communications through the HA are with
identical parties as those over the RO path, and it leverages the
existing IPsec mechanisms.

I would like to hear other opinions about this.  Particularly, answers
to the questions "Why *not* require securability via IPsec?" would be
helpful.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 07 Jun 2007 22:55:14 +0200

Hi Wesley,

> to the questions "Why *not* require securability via IPsec?" would be

	I'm not familiar to the work done in the BTNS WG, although I'll take a
look to it (it seems very interesting). Without knowing the details of
that on-going work (I'll provide more comments after looking at it), I'd
say that IMHO main advantages of using a not IPsec-based RO solution
are: no need to change CNs (to support the mechanisms defined by BTNS)
and no high additional delay in the handover. Besides that, it might be
important to analyse the threat model of a NEMO RO solution and evaluate
if a BTNS-based approach is effective at mitigating these threats,
compared with a standard MIPv6-based approach.

	Kind Regards,

	Carlos

---

From: "Roberto Baldessari" <[email-masked]>
Date: Mon, 11 Jun 2007 10:59:41 +0200

Hi all,

I support the idea that relying on a PKI could be possible, at least in some particular scenarios. 
For vehicular communications, for example, it seems like PKIs will be needed anyway (i.e. regardless from usage of NEMO).
Of course, a Return Routability-like solution would require less on the infrastructure side, but as we know, it is not easily applicable to NEMO.
Therefore, IMO IPsec/Certificate-based solutions should also be considered.

> [Carlos]
> provide more comments after looking at it), I'd say that IMHO 
> main advantages of using a not IPsec-based RO solution
> are: no need to change CNs (to support the mechanisms defined 
> by BTNS) and no high additional delay in the handover. 
>

[Roberto]
Regarding the first point (no changes to CNs), it depends which kind of CN is your starting point. I guess you assume CNs implement MIPv6. But if they don't, then you have to chenge them anyway, so you could do it directly for a NEMO-RO solution. In some scenarios where CNs are not random nodes in the Internet but dedicated hosts deployed from scratch (e.g. control/info centers), IMHO we can be less strict concerning changes in the CN.

Regarding handover delay, it depends. For example, if the CN only has to check locally a certificate and not contact the CA every time, then the delay might be even shorter than a MIPv6 RR-like solution.

Best regards,

Roberto

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 11 Jun 2007 11:06:25 +0200

Hi Roberto and all,

> Therefore, IMO IPsec/Certificate-based solutions should also be considered.

	I agree that a PKI solution can be a very good and simple solution for
AOS and ATS, but I don't think the same for the traffic of the
passengers. Actually, maybe it'd be better to design different solutions
for each type of traffic, since the requirements are quite different
(specially those related to security).

> Regarding the first point (no changes to CNs), it depends which kind of CN is your starting point. I guess you assume CNs implement MIPv6. But if they don't, then you have to chenge them anyway, so…

	If we want to have a solution that can be deployed in the short-term,
the most that we can assume is MIPv6-enabled CNs, but nothing more, IMHO
(again, talking about the user traffic, not AOS or ATS that have
different constraints). We cannot assume PKIs nor support at CNs for a
modified IPsec processing, derived from the work done at BTNS.

> Regarding handover delay, it depends. For example, if the CN only has to check locally a certificate and not contact the CA every time, then the delay might be even shorter than a MIPv6 RR-like sol…

	Yes, in that case, it might be shorter, but I was think about a
BTNS-like solution (I don't know how it'd work, but it might be possible
that it adds an additional delay).

	Kind Regards,

	Carlos