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

From: "Roberto Baldessari" <[email-masked]>
Date: Fri, 1 Jun 2007 10:08:49 +0200

Hi Wesley,

See my comment inline 

> 
> > - Req4 (availability): in my opinion any RO scheme will 
> alleviate the 
> > problem of a single point of failure instead of creating 
> it. Or do you 
> > mean that RO should work even if the HA is not available? We also 
> > pointed out this, but then I've realized that 
> "internet-less" RO might 
> > distract the WG and prevent it to come to (at least) a 
> basic RO scheme 
> > MIPv6-like. RO without infrastructure should better be the focus of 
> > other WGs
> 
> 
> Personally, I hadn't been thinking about the Internet-less 
> case of not being able to reach any HA, but rather I was 
> trying to say that it won't be acceptable for a solution to 
> only work under the assumption that a single MR services a 
> mobile network, or a single HA or access router services an 
> MR (or set of MRs).
> 
> In other words, we need the solution to co-exist peacefully 
> with both HA reliability mechanisms (e.g. the one MIP6 is 
> working on), multihoming mechanisms, and with multiple MRs.
> 
> Do you think it would be more clear if I added a sentence 
> that specifically excluded Internet-less operation from being 
> required?
> 

Now it is clear. I don't think that you need to mention the internet-less scenario. Maybe just a sentence about what you wrote here, i.e. RO compatible with multiple MRs serving the same mobile network. I did not immediately think about this case simply because in our scenario we consider a single MR.

>  
> > - Req6 (scalability): it is hard to determine whether an RO 
> scheme is 
> > scalable in terms of signaling, as it depends on other variables 
> > (network capacity, mobility,...). More than a absolute 
> requirement, I 
> > consider this as an important criterion in relative terms. I.e. a 
> > solution with lower signaling will be preferred compared 
> with one with 
> > higher signaling
> 
> 
> Agreed; this is an important metric, but one that's fairly 
> scenario-dependent in measurement and evaluation.  For 
> aircraft, the mobility patterns are tough to guess at because 
> they depend on the link technologies used.  Since many of the 
> current links are very low-rate, basing an analysis on them 
> may not be particularly useful, although I gave some rough 
> estimate of the time between changing VDL channels in the 
> draft.  I will check and see if the COCR document from the 
> FAA/Eurocontrol Future Communications Study has any guidance 
> on how we can specify scalability in greater detail for aeronautics.
> 
>  

Actually I wanted to say that since giving details on scalability at this stage is hard, maybe instead of as a requirement scalability could be mentioned as more general recommendation (e.g. desirable characteristic). But this is also questionable, because a solution that does not scale simply based on the number of aircrafts will not be considered at all. So, you could also leave it like this and mention that at this stage you refer to scalability considering only number of aircrafts and not other at the moment unknown variables (link capacity, number and distribution of HAs, etc).

> > - Req8 (security): I think it would be beneficial to 
> specify whether 
> > or not you require IPsec to be usable for LFN or only in the RO 
> > signaling or in the tunnel MR-HA. We will also try to specify 
> > something more about security in the automotive requirements.
> 
> 
> I think it should be possible to use in both cases, although 
> it must be understood that in some cases, the security 
> mechanisms can undo the RO, as Will Ivancic is very good at 
> explaining :).  My goals for this requirement were to (1) 
> ensure that the data used to make RO decisions can be 
> authenticable, and (2) ensure that flows using transport-mode 
> IPsec can use RO between the two end-points, and flows using 
> tunnel-mode IPsec can get RO between the MR and the 
> groundward side of the tunnel.
> If I put some more explanation of this into the draft, would 
> that help?

Yes, it would definitely help. It's reasonably clear to me now.

> 
> I would be interested in reviewing the automotive 
> requirements, if/when they are available.  I'm not sure how 
> similar they will be to the aero requirements, but it would 
> be really neat if a common solution was acceptable for both.
> 

We produced and presented a -00 draft in Prague http://tools.ietf.org/wg/nemo/draft-baldessari-c2ccc-nemo-req-00.txt.
It does not say much specifically about RO requirements, yet.
So, we'll try to be more specific in -01, for which I'd be really glad to have your comments.

Best regards,

Roberto

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 01 Jun 2007 10:30:38 +0200

Hi Wesley,

	I've not read your I-D in detail yet, but I have a question regarding
the requirement of security (Roberto actually triggered that).
When you say that are some security mechanisms that can undo the RO, do
you mean that are several circumstances where a security mechanism can
prevent an RO solution from taking place? would it be OK for an RO
solution not to work for some IPsec configurations while work for others
or is it necessary to support all?

	I'll try to provide more comments soon.

	Kind Regards,

	Carlos

>  
> > - Req8 (security): I think it would be beneficial to specify whether
> > signaling or in the tunnel MR-HA. We will also try to specify something
> > more about security in the automotive requirements.
> 
> 
> I think it should be possible to use in both cases, although it must be
> understood that in some cases, the security mechanisms can undo the RO,
> as Will Ivancic is very good at explaining :).  My goals for this
> requirement were to (1) ensure that the data used to make RO decisions
> can be authenticable, and (2) ensure that flows using transport-mode
> IPsec can use RO between the two end-points, and flows using tunnel-mode
> IPsec can get RO between the MR and the groundward side of the tunnel.
> If I put some more explanation of this into the draft, would that help?
> 
> I would be interested in reviewing the automotive requirements, if/when
> they are available.  I'm not sure how similar they will be to the aero
> requirements, but it would be really neat if a common solution was
> acceptable for both.
> 
-- 
¡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: Fri, 1 Jun 2007 12:07:43 -0400

> 	I'll try to provide more comments soon.

An easy way to explain this is that if tunnel-mode IPsec is used, the RO
scheme can't possibly optimize the end-to-end packet flow, only the
IPsec tunneled portion of it.  Imagine the ground-side IPsec gateway
is nearby the HA, and it's clear that RO bought very little.

I don't believe this is a problem with the protocols, but rather with
the way that people choose to apply them, or create policies without
considering how they impact other parts of the system when combined.
So, it's not really something that impacts RO requirements, just
something to be aware of when building and deploying systems that use
RO.

-- 
Wesley M. Eddy
Verizon Federal Network Systems