Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 30 Mar 2006 11:37:34 -0800

Alex,

Thanks See comments inline.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, March 30, 2006 1:36 PM
> To: Tsirtsis, George
> Cc: [email-masked]
> Subject: Re: [nemo] Soliciting comments on
draft-ietf-nemo-v4-base-00.txt
> 
> Tsirtsis, George wrote:
> > 4.2.  Mobile Network Acknowledgement Extension
> >
> >    ...  A Registration
> >    Reply may have either or both Implicit Mode Acknowledgement or
> >    Explicit Mode Acknowledgement extensions.
> >
> >
> > GT> The last "or" should be "and" I think?
> 
> Would a clearer reformulation:
> 
>    A Registration Reply may contain any non-zero number of Explicit
Mode
>    and Implicit Mode Acknowledgements sub-types. Both sub-types can be
>    present in a single Registration Reply.
> 
> work?  Any other?

[GT>] Sounds good

> 
> > 5.  Mobile Router Operation
> >
> >   ...
> >
> >    o  Set up default route via this tunnel or roaming interface when
> >       registered with or without reverse tunneling, respectively
> >
> > GT> What is a roaming interface?? I think I know what you mean but
is
> > roaming interface a well defined term?
> 
> Right... No, "roaming interface" is not defined anywhere.
> 
> RFC3753 "Mobility Related Terminology" does define "egress interface".
> "Egress interface" is used by RFC3963 NEMOv6 with the same same
meaning
> as in this draft.
> 
> However, "egress interface" is (1) a term largely used in contexts
other
> than mobility and (2) confusing.  In current speech the meaning of
> "egress" depends largely on some particular topology.  With some
> sketches just turn the page 180 degrees, or the point of view, and
> "egress" becomes "ingress".  What's "egress" for me is "ingress" for
my
> ISP.  "Roaming interface" can't be confused this way.
> 
> I do agree with the textual definition in the terminology RFC and with
> its use in RFC3963 NEMOv6, but less with using text "egress".
> 
> So I was thinking "roaming interface" may be fine.  Or otherwise
"mobile
>   interface"?
> 
> Would it be ok substituting "egress interface" for "roaming interface"
> in this draft?  Any other term for this interface?
> 
[GT>] "egress interface" is what you are talking about and I think is a
well understood term.

> > GT> This section I think should also say something about what the
Mobile
> > Router is supposed to do if it receives an explicit mobile network
ack
> > extension for a prefix that it did not explicitly ask for i.e., it
> > should make the prefix available to the mobile network, route
packets
> > for it etc etc.
> 
> You mean it "shouldn't" instead of "should"?
> 
> New text proposed, in section 5 "Mobile Router Operation":
> 
>    As per RFC3344, when the Mobile Node sends a Registration Request
it
>    saves the following information:
>        -  the link-layer address of the foreign agent to which the
>           Registration Request was sent, if applicable,
>        -  the IP destination address of the Registration Request,
>        -  the care-of address used in the registration,
>        -  the Identification value sent in the registration,
>        -  the originally requested Lifetime, and
>        -  the remaining Lifetime of the pending registration.
> 
>    Additionally, when the Mobile Node acts as a Mobile Router it
should
>    also save:
>        -  the Mobile Network Prefix(es) it counts using if
registration
>           successful.
>        -  the respective prefix length(s).
> 
> In section 5.1 "Error Processing"
> 
>    It is possible that the Mobile Router receives a Registration Reply
>    containing prefixes for which it did not send a Registration
Request.
>    (The Mobile Router can check this with the help of information it
>    saved prior to sending this Registration Request.)  In such case
>    the Mobile Router SHOULD...
> 

[GT>] SHOULD...what? I am missing what you are trying to say here.

> > 5.1.  Error Processing
> >
> > ..
> >
> >    If the value of the Code field in the Registration Reply is set
to
> >    HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile
Router
> >    MUST stop sending Registration Requests with any Mobile Network
> >    Prefix extensions to that Home Agent.
> >
> > GT> How would an HA that does not support Mobile networks know to
send
> > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this
> > problem later by saying that if the HA does not include a mobile
network
> > ack extension the MN should assume that the HA does not support
mobile
> > networks.
> 
> HA_MOBNET_UNSUPPORTED for HAs that today support MRs and tomorrow no
and
> after tomorrow again yes?
> 
> HA_MOBNET_UNSUPPORTED for migration?  Somebody may implement a
> pre-production HA that doesn't "yet" support MRs and then on day D
> switch to a full implementation, thus easing informing the remote MN
it
> could become an MR?
> 
> Or do you propose eliminating HA_MOBNET_UNSUPPORTED altogether?
> 
[GT>] Yes I propose eliminating the error code. HAs that do not support
NEMO extensions will simply ignore them and the MN already knows how to
deal with that. See below also

> > GT> Also, why don't you just use the code in the mobile network ack
> > extension to indicate mobile network specific errors and use an
existing
> > code in the registration reply header?
> 
> We use error codes both in the RegRep _and_ in the Mobile Network Ack
> extension to offer finer control to HA and MR.
> 
> The error codes in RegRep are high-level, like "NEMO not supported" or
> "this HA can't allow this MR's Home Address be a MR".  The ones in the
> extension are specific to particular Mobile Network Prefixes and their
> faults.
> 

[GT>]  See above, I am suggesting to remove the NEMO specific error code
in RREP.

> > I think this would make backwards compatibility easier.
> 
> How?
> 

[GT>] Because any HA that does not support NEMO does not have to do
anything. HAs that support NEMO....well they support NEMO and they do
not need to send an error code saying that they do not support NEMO. An
HA that supports NEMO but it is configured not to use it, can operate
the same way with an HA that does not support NEMO.

> Error codes in the RegRep header are defined as extensible (start from
> 127 and above or so).  A legacy non-NEMO MN not understanding some
error
> code there would just drop it or so.
> 

[GT>] A legacy MN will never request a prefix so it will never receive a
NEMO specific error code.

> > 6.3.  Mobile Network Prefix Registration
> >
> > ...
> >
> >   If the check fails or
> >    if the Mobile Router is not authorized for using any of those
> >    prefixes, the Home Agent MUST reject the registration request
with
> >    Mobile Network Acknowledgement Extension code
MOBNET_UNAUTHORIZED.
> >
> > GT> This may be an optimization but since you have code fields in
the
> > mobile network ack extension, why can't you reject the specific
prefix
> > that was not allowed and accept everything else?
> 
> For saving error code space in the regrep header?
> 
> For finer per-prefix control?
> 
> Probably one way would be to have one error code in the regrep header
> saying "see below there is some error with some prefix" and below it
> have extensions each specifying which prefix is successful and which
not
> and how.
> Is this what you mean?

[GT>] Not exactly. If the HoA is acceptable to the HA the registration
should be accepted and the RREP code should be set to "0". The HA is
supposed to also return a Mobile Network Ack extension, including a Code
for each prefix requested. This Code could indicate whether the specific
prefix was accepted or rejected. The MN has to parse all the extensions
anyway so it will see all this.

> 
> >    On the other hand, if check passes for every requested Mobile
Network
> >    Prefix, the Home Agent MUST attempt to set up forwarding for all
the
> >    Mobile Network Prefixes included in the registration request.  If
> >    forwarding set up fails for any of the prefixes, the Home Agent
MUST
> >    reject the registration request with Mobile Network
Acknowledgement
> >    Extension code MOBNET_FWDING_SETUP_FAILED.
> >
> > GT> Could you clarify what problem you are trying to solve with
this?
> > Why would forwarding fail???
> 
> No disk space, not enough virtual memory at HA, etc.
> 
> When HA receives a request to setup forwarding it usually creates new
> data structures for that particular prefix.  If not enough space then
> setting up forwarding may fail, no?
> 
> Calling a ioctl SIOCADDRT to set up a new route to a potentially
> "virtual" interface may fail for a number of additional reasons, like
no
> right metric ("1" should be fine), no more "virtual" interface space
> (number of possible virtual interfaces is defined at boot time) and
more
> I believe.
> 
> Do you think this option is not needed?
> 

[GT>]  it is fine

> > 9.  Security Considerations
> > ...
> >    All registration requests and replies MUST be authenticated by
the
> >    MN-HA Authentication Extension as specified in ([RFC3344]).
> >
> >
> > GT> Why are you changing what the RFC3344 requires? The RFC requires
an
> > authorization enabling extensions of which MN-HA auth is only one. I
> > think this should be kept as is.
> 
> Ok, what text in rfc3344 says that the Mobile-Home Authentication
> Extension is only one possibility and others are possible?  I think
it's
> the only possibility.  Is the alternativity opening you're talking
about
> the choices around MD5?
> 
> But I do agree we should have a NEMOv4 Security Considerations section
> very similar and sourced from the rfc3344.  We tried to do just that.
> 
> The HA ingress filtering text may be improved to express it as
> "additional" rules to the ones in rfc3344.
> 

[GT>]  Yes, what I am saying is that you should only define things in
addition to RFC3344. No need to repeat things that are the same.

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Mar 2006 17:11:34 +0200

Tsirtsis, George wrote:
>>> GT> What is a roaming interface?? I think I know what you mean 
>>> but is roaming interface a well defined term?
>> RFC3753 "Mobility Related Terminology" does define "egress 
>> interface". "Egress interface" is used by RFC3963 NEMOv6 with the 
>> same same meaning as in this draft.
>> 
>>  other than mobility and (2) confusing.  In current speech the 
>> meaning of "egress" depends largely on some particular topology. 
>> With some sketches just turn the page 180 degrees, or the point of 
>> view, and "egress" becomes "ingress".  What's "egress" for me is 
>> "ingress" for my ISP.  "Roaming interface" can't be confused this 
>> way.
>> 
>> I do agree with the textual definition in the terminology RFC and 
>> with its use in RFC3963 NEMOv6, but less with using text "egress".
>> 
>> "mobile interface"?
>> Would it be ok substituting "egress interface" for "roaming 
>> interface" in this draft?  Any other term for this interface?
>> 
> [GT>] "egress interface" is what you are talking about and I think is
>  a well understood term.

Ok I'll use "egress interface" instead of "roaming interface".

>>> Mobile Router is supposed to do if it receives an explicit mobile
>>>  network ack extension for a prefix that it did not explicitly
>>> ask for i.e., it should make the prefix available to the mobile
>>> network, route packets for it etc etc.
>> it saves the following information: -  the link-layer address of
>> the foreign agent to which the Registration Request was sent, if 
>> applicable, -  the IP destination address of the Registration 
>> Request, -  the care-of address used in the registration, -  the 
>> Identification value sent in the registration, -  the originally 
>> requested Lifetime, and -  the remaining Lifetime of the pending 
>> registration.
>> 
>> should also save: -  the Mobile Network Prefix(es) it counts using
>> if registration successful. -  the respective prefix length(s).
>> 
>> Request. (The Mobile Router can check this with the help of
>> information it saved prior to sending this Registration Request.)
>> In such case the Mobile Router SHOULD...
>> 
> 

I thought you suggest and have an idea about what should the MR do when
it receives a prefix in the RegRep for which it didn't send a RegReq. I
think the MR shouldn't do anything.

>>  switch to a full implementation, thus easing informing the remote 
>> MN it could become an MR?
>> 
> [GT>] Yes I propose eliminating the error code. HAs that do not 
> support NEMO extensions will simply ignore them and the MN already 
> knows how to deal with that. See below also

Ok.

>>> GT> Also, why don't you just use the code in the mobile network 
>>> ack extension to indicate mobile network specific errors and use 
>>> an existing code in the registration reply header?
>> We use error codes both in the RegRep _and_ in the Mobile Network 
>> Ack extension to offer finer control to HA and MR.
>> 
>> The error codes in RegRep are high-level, like "NEMO not supported"
>>  or "this HA can't allow this MR's Home Address be a MR".  The ones
>>  in the extension are specific to particular Mobile Network
>> Prefixes and their faults.
>> 
> 
> [GT>]  See above, I am suggesting to remove the NEMO specific error 
> code in RREP.

Ok will remove the HA_MOBNET_UNSUPPORTED if others don't object.

>  not need to send an error code saying that they do not support NEMO.
> An HA that supports NEMO but it is configured not to use it, can
> operate the same way with an HA that does not support NEMO.

Sounds perfectly logic.

>> Error codes in the RegRep header are defined as extensible (start 
>> from 127 and above or so).  A legacy non-NEMO MN not understanding 
>> some error code there would just drop it or so.
>> 
> 
> [GT>] A legacy MN will never request a prefix so it will never 
> receive a NEMO specific error code.

Ok.

>>> If the check fails or if the Mobile Router is not authorized for 
>>> using any of those prefixes, the Home Agent MUST reject the 
>>> registration request with Mobile Network Acknowledgement
>>> Extension code MOBNET_UNAUTHORIZED. GT> This may be an
>>> optimization but since you have code fields in the mobile network
>>> ack extension, why can't you reject the specific prefix that was
>>> not allowed and accept everything else?
>> Probably one way would be to have one error code in the regrep 
>> header saying "see below there is some error with some prefix" and 
>> below it have extensions each specifying which prefix is successful
>>  and which not and how.
>> 
>> Is this what you mean?
>> 
> 
> 
> [GT>] Not exactly. If the HoA is acceptable to the HA the 
> registration should be accepted and the RREP code should be set to 
> "0". The HA is supposed to also return a Mobile Network Ack 
> extension, including a Code for each prefix requested. This Code 
> could indicate whether the specific prefix was accepted or rejected. 
> The MN has to parse all the extensions anyway so it will see all 
> this.

Right.

>>> Network Prefix, the Home Agent MUST attempt to set up forwarding
>>> for all the Mobile Network Prefixes included in the registration
>>> request.  If forwarding set up fails for any of the prefixes, the
>>> Home Agent MUST reject the registration request with Mobile
>>> Network Acknowledgement Extension code
>>> MOBNET_FWDING_SETUP_FAILED.
>>> 
>>> this? Why would forwarding fail??? No disk space, not enough
>>> virtual memory at HA, etc.
>> 
>> When HA receives a request to setup forwarding it usually creates 
>> new data structures for that particular prefix.  If not enough 
>> space then setting up forwarding may fail, no?
>> 
>> "virtual" interface may fail for a number of additional reasons, 
>> like no right metric ("1" should be fine), no more "virtual"
>> interface space (number of possible virtual interfaces is defined
>> at boot time) and more I believe.
>> 

Ok.

>>> 9.  Security Considerations ... All registration requests and 
>>> replies MUST be authenticated by the MN-HA Authentication
>>> Extension as specified in ([RFC3344]).
>>> 
>>> 
>>> GT> Why are you changing what the RFC3344 requires? The RFC 
>>> requires an authorization enabling extensions of which MN-HA auth
>>> is only one. I think this should be kept as is.
>> it's the only possibility.  Is the alternativity opening you're
>> talking about the choices around MD5?
>> 
>> But I do agree we should have a NEMOv4 Security Considerations 
>> section very similar and sourced from the rfc3344.  We tried to do 
>> just that.
>> 

Ok.

Alex