NEMO Basic Support update

1
NEMO Basic Support update

• IETF 61

2
Status

• IANA assignments done
• Very close to AUTH48 call
• Some issues raised recently
• We need to figure out if we want to make these
  changes now (potential delay) or do it later in a
  bis draft

3
Proposed changes since IESG approval

• All changes discussed on the WG mailing list
• http//people.nokia.net/vijayd/nemo/changes.html
• Changes classified as
• Critical changes
• If this change is not made, the protocol will not
  function, will create an unacceptable security
  problem, or will be problematic for the Internet.
• Critical changes require document recycled
  through the WG last call, IETF last call, etc.
• Important changes
• If this change is not made, interoperability
  might be affected
• WG consensus required for the changes, IESG needs
  to be made aware of the changes, done during
  AUTH48
• Desirable changes
• This change would clarify a point, make sections
  of the document consistent, or would ease
  implementation decisions.
• Options
• Do it later in a bis document
• Treat them just as important changes
• WG chairs recommend they be done later in a bis
  document
• Minor changes
• Done during AUTH48, AD approval required

4
Critical Issues

• None

5
Important Changes

• Issue 42 (http//people.nokia.net/vijayd/nemo/issu
  e42.txt)
• Is it okay for the MR to exclude prefixes in
  binding update sent to update existing binding
  cache entries?
• Has the MR switched to using implicit mode?
• How does the MR stop using certain prefixes and
  continue using other prefixes while still
  maintaining the binding cache entry?
• Resolution
• MR includes all prefixes in every binding update
  (even the ones which refresh an existing binding
  cache entry)
• Home Agent behavior
• If a refresh BU contains a prefix that is not in
  existing BCE, setup forwarding for the prefix
• If a refresh BU does not contain a prefix that is
  in existing BCE, stop forwarding for the prefix

6
Important Changes (contd.)

• Binding Ack status values
• MR discards BAck with status values 141 and 142
  in implicit mode
• 141 Invalid Prefix
• 142 Not Authorized for Prefix
• MR discards Back with status value 143 in
  explicit mode
• 143 Forwarding Setup failed (prefixes missing)
• Most probably due to mis-configuration
• Silent discard is not good for user experience
• MR pretends nothing is happening
• Proposal
• Treat them as fatal errors
• Could generate an error on the user interface
• No change on the wire

7
Important Changes (contd.)

• The use of tunnel encapsulation limit
• It was specified wrong in the document
• Tunnel encapsulation limit cannot be used by the
  MR to limit the number of nested MRs
• Resolution
• Remove the paragraph
• Issue 39 (http//people.nokia.net/vijayd/nemo/issu
  e39.txt)
• Conflicting requirements for setting lifetime in
  router advertisements sent by mobile routers on
  the egress interface
• SHOULD and MUST used
• Resolution
• Change to SHOULD everywhere

8
Important Changes (contd.)

• Add the following text to the security
  considerations section
• If the Mobile Router sends a Binding Update
  with a one or more Mobile Network Prefix options,
  the Home Agent MUST be able to verify that the
  Mobile Router is authorized for the prefixes
  before setting up forwarding for the prefixes.
• Binding Ack status 143
• Forward Setup failed doesnt say why it failed
  (explained in text but not obvious by just
  looking at the string associated with the status
  value)
• Proposal
• Change to Forwarding Setup failed (missing
  prefixes)
• Any other change would require IANA updating
  their registries

9
Important Changes (contd.)

• Sending routing updates on the visited link
• Earlier text
• When the mobile router moves and attaches to a
  visited network, it MUST stop sending routing
  updates on the interface with which it attaches
  to the visited link.
• Cant be enforced by the visited link
• Wrong use of the MUST keyword
• New text
• When the Mobile Router moves and attaches to a
  visited network, it should stop sending routing
  updates on the interface with which it attaches
  to the visited link.
• They will be dropped by the visited link if
  authentication of routing protocol messages is
  enabled on the visited link

10
Other changes

• Desirable changes
• Changes to improve readability (and clarity)
• Please see http//people.nokia.net/vijayd/nemo/cha
  nges2.txt
• Minor changes
• Please see http//people.nokia.net/vijayd/nemo/cha
  nges3.txt

11
Conclusions

• There are no critical changes that indicate
  protocol is broken
• A few changes are needed to make sure
  interoperability is achieved
• There are some changes that improve the text
• Authors recommendation
• The proposed changes dont require recycling the
  document to the WG
• IESG members should be made aware of the changes
• Do the changes during AUTH48